Wiki: x11 guide

[matu3ba]

Summary

1. Xpra 4.x version works out of the box. However, it has input delay of around 0.5seconds.
2. Xephyr has less input dela, but it is a mess to setup. Once Xephyr gets configurated, it breaks Xpra.
   We could sandbox the sandbox setup to fix this or use an overlay, but thats too much clutter.

Xpra
just works, but with constant lag :(

Xephyr

1. Xephyr clibpoard only has a copy-to-all clipboards solution, which leaves room for clipboard attacks and application sneaking the clipboard. Xephyr also takes some setup.
2. A suggested clipboard solution xclipsync does NOT work for me.
3. If -extension MIT-SHM is used, no shared memory (more secure)

TODOs

X11

• Document and add extensions like -extension MIT-SHM
• Document needed xpra version, test xpra (+clipboard)

Wayland

• Known security caveats of implementations => stuff that runs on X11 without user knowledge (login manager)
• No guarantee or user indication, if applications use Wayland (it may just refuse to do without extra setup like firefox)
• Document how to always start applications with Wayland(GTK,Qt)
• (too much effort) Document how to sandbox XWayland (replace login manager, rewrite session handling in elogind/logind) just disallow X11
• Need to check with xlsclients(requires restart), xeyes, xwininfo, starting application with DISPLAY='' app or WAYLAND_DEBUG=1 app in contrast to grepping for display ports hack around with a huge command / upstream stuff to firejail?!
• Application specific mitigations => force Wayland and see, if stuff crashes => then use an alternative
• Many distros dont ship a separate name to indicate that the application definitely uses wayland dont trust distros, they dont even manage to deprecate non-XDGBDS conforming applications
• Login managers of distros still all use X11 (session management interaction?) no useless work
• Each login manager uses its own scripts for the Wayland and Xwayland session, but default X11 installation setup remains in /etc/X11 no useless work

[matu3ba]

The old x11 guide is here and the new one will be here. For now it is more of a stub.

The wiki should live at git@github.com:netblue30/firejail.wiki.git, so I cant push images.
@netblue30 Should I link the images from your x11 guide as github user content or move into a folder wiki/images / doc/image and link from the wiki?

man firejail-config is missing on my distribution(arch-based endeavour) imho.

[matu3ba]

@rusty-snake Can you review?

I did only find this half-baked scripting solution for synchronizing the clipboard.
The other solution xclipsync did not work for me.

Do you have any idea what to use?

[rusty-snake]

I'm on wayland for two years or so. So IDK too much about this, but here are three things I noted:

1. Why should I use this?: X11 is unsafe, no matter if it is used over an abstract or normal socket is used
2. How do I get NET? (ip addr show)
3. You current firejail commandline, will break if e.g falkon.profile does not contains openbox in its ${PATH} (e.g. private-bin is used). The last time I used X11-sandboxing, I started xephyr+openbox in one sandbox and the started e.g falkon in another sandbox and set DISPLAY.

[matu3ba]

@rusty-snake Could you exemplify what on X11 remains unsafe, if one uses network namespaces + sandboxing?
Just curious: Do you use Sway, Gnome or tty/no Desktop Environment? For me KDE is very unstable and uses alot CPU on idle.

I fix 2+3 later.

[rusty-snake]

1. IDK if you got me, but I mean the unsafe parts of X11 are not that unrelated to the socket which is used by the sandboxed program.

Could you exemplify what on X11 remains unsafe, if one uses network namespaces + sandboxing?

If you restrict the X11 access of a sandbox to Xephyr (of whatever) it can obviously no longer do bat things like key-logger. So the most holes are closed. X11 is the only reason why we can not use ipc-namespace for graphical programs and almost every flatpak has --share=ipc.

Just curious: Do you use Sway, Gnome or tty/no Desktop Environment? For me KDE is very unstable and uses alot CPU on idle.

I follow the Wayland development of KDE since 2017. kwin_wayland looks good to me. However QT/KDE with Wayland is a torture. Crash, ugly window, broken clipboard, crash again, ... . GTK has full wayland support since 2015. Even firefox has good wayland support since 78 or so (before 78 you had crashes if you left-click on the wrong spot, open add-on pop-overs, ... every release a new crash, but now it's pretty good). To your question I use GNOME. The last time I tried sway (before 1.0, around summer 2018) it was lacking too much features.

[matu3ba]

Thanks for the insight.

1. As I understand it, one can still abuse the shared memory region of the x11-server. Is there more you can think of?

2. Did you test x11docker (description) yet?
   This looks like an excellent tool to compare firejail with.

1+2 I found the option

--hostipc sets docker run option --ipc=host. Allows MIT-SHM / shared memory. Disables IPC namespacing.

We could steal copy the config.

[rusty-snake]

1. IDK if it can abuse the shared-memory of the host-X11-server. However, we can not harden the sandbox with ipc-namespace as long as it uses X11.
2. No, never used.

[matu3ba]

3. You current firejail commandline, will break if e.g falkon.profile does not contains openbox in its ${PATH} (e.g. private-bin is used). The last time I used X11-sandboxing, I started xephyr+openbox in one sandbox and the started e.g falkon in another sandbox and set DISPLAY.

Do you mean like this?

DISPLAY=":150" firejail Xephyr $DISPLAY
DISPLAY=":150" firefox --no-remote

firemon --x11 returns all possible display numbers and firejail --x11 does return the current display number only as debug output for the user and not scriptable.

[rusty-snake]

Something like this, but I don't remember.

firejail --x11=xephyr --net=eth0 openbox &
firejail  --env=DISPLAY=:123 --net=eth0 firefox

[matu3ba]

Something like this, but I don't remember.

firejail --x11=xephyr --net=eth0 openbox &
firejail  --env=DISPLAY=:123 --net=eth0 firefox

Thats not scriptable, since the status code of the first line $? remains zero and DISPLAY in my shell environment remains ":0".

[matu3ba]

TODOs:

• Rewrite xpra section, since a recent version just works.
• Package xpra on arch/endeavour?
• Document xpra and xephyr incompatibilities of configuration
• Figure out, if it is possible to disable MIT-SHM / shared memory on x11, xpra or xephyr
• Change firejail --x11 output or firemon --x11 to have a scriptable output

If we can disable MIT-SHM / shared memory and performance is reasonable, we can use IPC namespacing.

[mviereck]

Figure out, if it is possible to disable MIT-SHM / shared memory on x11, xpra or xephyr

In Xephyr, just set option -extension MIT-SHM to disable it. (A + would enable it).
xpra does not directly provide an option to disable MIT-SHM, but you can run a custom Xvfb command with disabled MIT-SHM or attach to an already running custom X/Xvfb server.
To disable MIT-SHM on regular Xorg started by a display manager, you can create a file in /etc/X11/xorg.conf.d.
Example:

$ ls /etc/X11/xorg.conf.d/disable-mit-shm.conf
Section "Extensions"
    Option "MIT-SHM" "Disable"
EndSection

You can check for enabled MIT-SHM with xdpyinfo | grep -q "MIT-SHM".

I don't have a solution for Xwayland started by a Wayland compositor.

[matu3ba]

I don't have a solution for Xwayland started by a Wayland compositor.

/usr/bin/Xwayland -help shows an option -extension name Disable extension, but breaks awkwardly the pipe.
Since I cant find any other specific paths for KDE, in the Wayland manual or in a search engine, I would assume that the standard paths for x11 configuration are used.

Since the manual leaves the option open to define the display variable yourself, this would mean multiple x11 servers which I find dubious (since x11 handles all kind of stuff).
Hence I asked on stackoverflow and will likely contact the x11/Wayland devs to improve their manual.

[matu3ba]

For sddm the configuration is in nvim /usr/lib/sddm/sddm.conf.d/default.conf and for my distro it uses /usr/share/sddm/scripts/Xsession for the scripts to start the Xorg session.

It is very annoying that Wayland provides no central place for the Wayland-specific config parts and every login manager has a different place.
At least for x11 there was a convention to place the startup scripts it into /etc/X11/ and the session scripts into xorg.conf.d.

xorg setup commands

# run all system xinitrc shell scripts.
if [ -d /etc/X11/xinit/xinitrc.d ]; then
  for i in /etc/X11/xinit/xinitrc.d/* ; do
  if [ -x "$i" ]; then
    . "$i"
  fi
  done
fi

# Load Xsession scripts
# OPTIONFILE, USERXSESSION, USERXSESSIONRC and ALTUSERXSESSION are required
# by the scripts to work
xsessionddir="/etc/X11/Xsession.d"
OPTIONFILE=/etc/X11/Xsession.options
USERXSESSION=$HOME/.xsession
USERXSESSIONRC=$HOME/.xsessionrc
ALTUSERXSESSION=$HOME/.Xsession

if [ -d "$xsessionddir" ]; then
    for i in `ls $xsessionddir`; do
        script="$xsessionddir/$i"
        echo "Loading X session script $script"
        if [ -r "$script"  -a -f "$script" ] && expr "$i" : '^[[:alnum:]_-]\+$' > /dev/null; then
            . "$script"
        fi
    done
fi

if [ -d /etc/X11/Xresources ]; then
  for i in /etc/X11/Xresources/*; do
    [ -f $i ] && xrdb -merge $i
  done
elif [ -f /etc/X11/Xresources ]; then
  xrdb -merge /etc/X11/Xresources
fi
[ -f $HOME/.Xresources ] && xrdb -merge $HOME/.Xresources

if [ -f "$USERXSESSION" ]; then
  . "$USERXSESSION"
fi

if [ -z "$*" ]; then
    exec xmessage -center -buttons OK:0 -default OK "Sorry, $DESKTOP_SESSION is no valid session."
else
    exec $@
fi

[matu3ba]

Maybe Wayland accepts changes to the Wayland standard for using XDG_BASE. My mail got ignored.

The need of tools like xeyes to check what programs use Xwayland (and conversely Wayland) is very annoying.

Starting XWayland sandboxed would require replacing the graphical login manager + rewriting invoking commands (in elogind or logind) of the display manager.

The rabbit hole of session management is also very deep.

The replacement login manager/display manager can be greetd or writing custom scripts/the Sway way of doing things.

[matu3ba]

@rusty-snake
Did you ever check with xeyes, if Chromium or Firefox are started on XWayland?

On my OS GTK appears to always start with XWayland (in contrast to Qt applications), which defeats the purpose of using Wayland.

(Firefox is also laggy and cant handle the content on maximizing, when using with KDE + Wayland. I can only use it on one screenside. I did not have issues with Falkon/Qt though.)

[rusty-snake]

Did you ever check with xeyes, if Chromium or Firefox are started on XWayland?

I use xlsclients.

On my OS GTK appears to always start with XWayland (in contrast to Qt applications), which defeats the purpose of using Wayland.

Use GDK_BACKEND=wayland CLUTTER_BACKEND=wayland if you want to change this.

(Firefox is also laggy and cant handle the content on maximizing, when using with KDE + Wayland. I can only use it on one screenside. I did not have issues with Falkon/Qt though.)

I can only talk about mutter (GNOME), but here firefox 80 is very stable now. No crashes, flickering, broken clipboard, wrong context-menu, ...

[matu3ba]

@rusty-snake
xlsclients -display :1 -a returns only

pc  xeyes

even though xeyes shows vlc to use X11 (uses GTK).

There are also no more apps with such functionality.
Interestingly vlc is still started on XWayland (shown by xeyes).
Qt applications however just work fine.

[rusty-snake]

xlsclients -display :1 -a returns only

I know it does not show all programs, on the other can it can show you X11-clints without window such as ibus. You can also use xprop, ... see https://fedoraproject.org/wiki/How_to_debug_Wayland_problems#Does_your_application_run_on_Wayland_natively.2C_or_uses_XWayland_.28X11_compatibility_layer.29.3F

There are also no more apps with such functionality.
Interestingly vlc is still started on XWayland (shown by xeyes).
Qt applications however just work fine.

Maybe the devs force X11 because the have bugs / missing features in wayland (HW-accel?). Or vlc still stuck on qt4.

[matu3ba]

@rusty-snake

Setting

enable media.ffmpeg.vaapi.enabled
enable gfx.webrenderer.all
disable media.ffvpx.enabled

mitigated the issues (mostly heavy flickering with javascript or on initial resizing/maximizing the window, which still on initial loading of javascript occurs and then generally disappears after 10-15 sec).
vaapi is for GPU acceleration, which is optional.

xlsclients may require a restart of the system after installation.

[matu3ba]

@rusty-snake @netblue30

This is expected behavior of Firefox.
"More recent versions of Firefox support opting into Wayland via an environment variable."

The Wayland standard implies probably unsecure applications, because it gives no user indication for its usage. This was just a big waste of time.

Can I write about this in a separate Wayland guide, since this may compromise user security?

[rusty-snake]

The Wayland standard implies probably unsecure applications, because it gives no user indication for its usage. … Can I write about this in a separate Wayland guide, since this may compromise user security?

What do you mean exactly?

FYI: Weston and sway can be used w/o XWayland AFAIK and GNOME is 2 or 3 release away from it.

[matu3ba]

What do you mean exactly?

FYI: Weston and sway can be used w/o XWayland AFAIK and GNOME is 2 or 3 release away from it.

Yes. However, many distros have XWayland and Wayland for compatibility. It is however not visually distinguished and easily checkable, if the program uses XWayland or Wayland.

Programs can choose as they please and it would be the distros job to prevent this or ship separate versions. However, few actually do this (due to maintenance costs and no easy way in the standard to check/no simple programs available).

[rusty-snake]

Ahhh, so you want to write a warning with some background and suggest to add a include disable-X11.inc to the most <program>.locals which supports it?

blacklist /tmp/.X11-unix
blacklist ${HOME}.Xauthority
blacklist ${RUNUSER}/.mutter-Xwaylandauth*
blacklist /tmp/.ICE-unix
blacklist ${RUNUSER}/ICEauthority
rmenv DISPLAY
rmenv XAUTHORITY

ipc-namespace

[rusty-snake]

#4451