#1489 - [GH-ISSUE #2220] Firejail passing MIT COOKIE on cmd line - visible in ps -auxw? - github-starred/firejail

gitea-mirror commented

2026-05-05 08:09:30 -06:00

Owner

Originally created by @Veek on GitHub (Oct 28, 2018).
Original GitHub issue: https://github.com/netblue30/firejail/issues/2220

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

Originally created by @Veek on GitHub (Oct 28, 2018). Original GitHub issue: https://github.com/netblue30/firejail/issues/2220 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](https://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

gitea-mirror closed this issue

2026-05-05 08:09:31 -06:00

gitea-mirror commented

2026-05-05 08:09:33 -06:00

Author

Owner

@crass commented on GitHub (Oct 29, 2018):

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.

@crass commented on GitHub (Oct 29, 2018): 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.

gitea-mirror commented

2026-05-05 08:09:34 -06:00

Author

Owner

@chiraag-nataraj commented on GitHub (Dec 8, 2018):

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

@chiraag-nataraj commented on GitHub (Dec 8, 2018): @Veek Also, if you want X11 sandboxing, why not just do `firejail --x11 xterm`?

gitea-mirror commented

2026-05-05 08:09:35 -06:00

Author

Owner

@Veek commented on GitHub (Dec 8, 2018):

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.

@Veek commented on GitHub (Dec 8, 2018): 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.

gitea-mirror commented

2026-05-05 08:09:36 -06:00

Author

Owner

@chiraag-nataraj commented on GitHub (Dec 8, 2018):

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.

@chiraag-nataraj commented on GitHub (Dec 8, 2018): > 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.

gitea-mirror commented

2026-05-05 08:09:37 -06:00

Author

Owner

@smitsohu commented on GitHub (Dec 9, 2018):

@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

@smitsohu commented on GitHub (Dec 9, 2018): @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

gitea-mirror commented

2026-05-05 08:09:38 -06:00

Author

Owner

@chiraag-nataraj commented on GitHub (May 20, 2019):

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.

@chiraag-nataraj commented on GitHub (May 20, 2019): 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.

gitea-mirror referenced this issue

2026-05-05 10:11:43 -06:00

[PR #1489] [MERGED] profile fixes and enhancements #3991

Rows
Columns

[GH-ISSUE #2220] Firejail passing MIT COOKIE on cmd line - visible in ps -auxw? #1489