Firejail: Firejail passing MIT COOKIE on cmd line - visible in ps -auxw?

[Veek]

I've been trying to understand how Firejail authenticates with the main Xorg server. I found this: bugs.debian.org/cgi-bin/bugreport.cgi?bug=526678
I ran this:
_firejail xpra start :20 --start-child=xterm --no-daemon --exit-with-children_ and did a quick _ps -auxww|grep xauth_ and I get this

test 10890 0.0 0.0 26396 1292 pts/2 S+ 16:11 0:00 xauth add :20 MIT-MAGIC-COOKIE-1 1b56f60e989f4ddfbc0ddf40380aca29

I'm on Debian so maybe it's different currently? Isn't this a problem? Maybe a named pipe can be used to pass credentials - initiated by the user of firejail with a timeout?

I get this error on Debian Stretch

Error trying to create XAUTHORITY file /root/.Xauthority: [Errno 13] Permission denied: '/root/.Xauthority'

I su from root to test and run that cmd and firejail's trying to add a cookie to my .Xauthority vs reading the cookie from a named pipe and allowing me to delete it from .Xauthority

[crass]

Firejail only uses xauth with its generate command (in recent versions). The command you're showing is for the xauth add command. You might try running pstree or strace to figure out the parent of that xauth command and report to the appropriate project. But it doesn't appear as though the culprit is firejail.

[chiraag-nataraj]

@Veek Also, if you want X11 sandboxing, why not just do firejail --x11 xterm?

[Veek]

Because firejail's just a rather crappy 'C' wrapper around Xpra, or-whatever your using.
-x11 Sandbox the application using Xpra, Xephyr, Xvfb or Xorg secu‐
rity extension
Xorg has no security barring the hidden /tmp abstract socket, so Xpra proxies each application using Xvfb - 1xXvfb/application - Xpra itself relies on python, so you essentially are running C/Firejail-->Python--->Xpra--->application1.

I'd rather just pass my credentials to the app/running-in-an-su-account and change my credentials, every time. It won't protect me from prying apps since Xorg has no way to restrict such things but it'll be fast and reasonably secure.

[chiraag-nataraj]

Because firejail's just a rather crappy 'C' wrapper around Xpra, or-whatever you're using.

Not really true? For example, one thing I noticed is that if I use firejail --x11, it automatically blocks all of the other sockets in /tmp/.X11-unix. If you set up the X11 sandbox yourself, you have to manually take care of that.

Also, if you use private-bin (which makes more sense for single-use programs like an email client or web browser or whatever), then you don't need to whitelist whichever X11 sandboxing tool you're using (since firejail will take care of spawning it).

Additionally, you can have a tighter sandbox since you can limit whatever needs to be whitelisted to the specific files the program itself needs rather than whatever the program needs + whatever xpra (or whatever) needs.

Fundamentally, there are actually quite a few reasons to prefer setting up the X11 jail with firejail rather than doing what you're doing here. And in any case, all of this is just a band-aid solution until we get real graphical isolation in Linux (i.e. native Wayland for all programs). You may also be interested in Qubes OS.

[smitsohu]

@Veek there exists a tutorial how to do it the right way https://firejail.wordpress.com/documentation-2/x11-guide/

EDIT: Missing in the tutorial, but with a mention in the man page, the abstract socket can be also turned off by passing -nolisten local on the Xorg command line

[chiraag-nataraj]

Going to go ahead and close the issue, since the original question seems to have been answered. @Veek, please feel free to re-open if you have more questions.