[GH-ISSUE #3211] --x11= and 777 permissions on new socket vs. other users #2010

New issue

Closed

opened 2026-05-05 08:40:48 -06:00 by gitea-mirror · 4 comments

gitea-mirror commented

2026-05-05 08:40:48 -06:00

Owner

Originally created by @jonleivent on GitHub (Feb 8, 2020).
Original GitHub issue: https://github.com/netblue30/firejail/issues/3211

Running in an x11 sandbox (firejail --x11=xephyr) creates the new /tmp/.X11-unix/X# socket with very weak (777) permissions, allowing users other than the creator of the jail access to the Xephyr display, which is running without any xauth settings. Also, the default configuration allows abstract socket connections as well.

I suggest disallowing abstract socket connections to the Xephyr display and creating the new X11 socket with 700 permissions. Then the jail owner can decide to weaken that, instead of racing to strengthen it vs. other users. Alternatively, generate new xauth for the owner alone, and have Xephyr require it.

firejail 0.9.58.2, Debian Buster.

Originally created by @jonleivent on GitHub (Feb 8, 2020). Original GitHub issue: https://github.com/netblue30/firejail/issues/3211 Running in an x11 sandbox (firejail --x11=xephyr) creates the new /tmp/.X11-unix/X# socket with very weak (777) permissions, allowing users other than the creator of the jail access to the Xephyr display, which is running without any xauth settings. Also, the default configuration allows abstract socket connections as well. I suggest disallowing abstract socket connections to the Xephyr display and creating the new X11 socket with 700 permissions. Then the jail owner can decide to weaken that, instead of racing to strengthen it vs. other users. Alternatively, generate new xauth for the owner alone, and have Xephyr require it. firejail 0.9.58.2, Debian Buster.

gitea-mirror closed this issue

2026-05-05 08:40:48 -06:00

gitea-mirror commented

2026-05-05 08:40:50 -06:00

Author

Owner

@jonleivent commented on GitHub (Feb 9, 2020):

I think I have a workaround for this, but I need some questions answered:

Is it the case that if I run Xephyr outside firejail, have it manage display 1, then with DISPLAY=:1, run a firejailed client, firejail will see the DISPLAY setting and whitelist /tmp/.X11-unix/X1 for that client? This seems to be the case in my testing. Is it also the case that, other than the somewhat separate firejail around Xephyr, there is no difference between this setup and using --x11=xephyr on the client? No other security protections are missing?

Because if this is the case, then I can run Xephyr outside the client's firejail and pass Xephyr an -auth option for that client. Indeed, this setup would solve several problems at once, as I would now be able to pass other options to Xephyr as well without having to edit firejail.config.

@jonleivent commented on GitHub (Feb 9, 2020): I think I have a workaround for this, but I need some questions answered: Is it the case that if I run Xephyr outside firejail, have it manage display 1, then with DISPLAY=:1, run a firejailed client, firejail will see the DISPLAY setting and whitelist /tmp/.X11-unix/X1 for that client? This seems to be the case in my testing. Is it also the case that, other than the somewhat separate firejail around Xephyr, there is no difference between this setup and using --x11=xephyr on the client? No other security protections are missing? Because if this is the case, then I can run Xephyr outside the client's firejail and pass Xephyr an -auth option for that client. Indeed, this setup would solve several problems at once, as I would now be able to pass other options to Xephyr as well without having to edit firejail.config.

gitea-mirror commented

2026-05-05 08:40:51 -06:00

Author

Owner

@smitsohu commented on GitHub (Feb 15, 2020):

I think all of your conclusions are correct, and this is a possible workaround.

When looking at Xephyr specifically, I'm unsure why there is this -ac option. I played around a bit without and it didn't seem necessary. In which case it could maybe be made optional and go the Firejail configuration file?

@smitsohu commented on GitHub (Feb 15, 2020): I think all of your conclusions are correct, and this is a possible workaround. When looking at Xephyr specifically, I'm unsure why there is this `-ac` option. I played around a bit without and it didn't seem necessary. In which case it could maybe be made optional and go the Firejail configuration file?

gitea-mirror commented

2026-05-05 08:40:52 -06:00

Author

Owner

@jonleivent commented on GitHub (Feb 15, 2020):

I am having considerable success with this configuration - separate Xephyr firejail and client firejail, launched together from a script. I am not using the -ac option, and am using the -auth option. I also had to alter Xephyr.profile a bit to make it work - removing private and home whitelisting via whitelist-common.inc. I have been trying to strengthen the sanboxing of Xephyr after those removals, but haven't found the right combo of whitelistings yet.

@jonleivent commented on GitHub (Feb 15, 2020): I am having considerable success with this configuration - separate Xephyr firejail and client firejail, launched together from a script. I am not using the `-ac` option, and am using the `-auth` option. I also had to alter Xephyr.profile a bit to make it work - removing private and home whitelisting via whitelist-common.inc. I have been trying to strengthen the sanboxing of Xephyr after those removals, but haven't found the right combo of whitelistings yet.

gitea-mirror commented

2026-05-05 08:40:52 -06:00

Author

Owner

@jonleivent commented on GitHub (Feb 17, 2020):

I'm closing this, as it certainly seems like running Xephyr separately with session-specific options and whitelisting the X11 socket it produces can be used to accomplish any matter of xauth protections, including preventing any time window where hijacking of that Xephyr session from outside is possible. All with no loss of sandbox protections.

@jonleivent commented on GitHub (Feb 17, 2020): I'm closing this, as it certainly seems like running Xephyr separately with session-specific options and whitelisting the X11 socket it produces can be used to accomplish any matter of xauth protections, including preventing any time window where hijacking of that Xephyr session from outside is possible. All with no loss of sandbox protections.

gitea-mirror referenced this issue

2026-05-05 10:14:40 -06:00

[PR #2010] [MERGED] don't include globals.local twice (take two) #4151

gitea-mirror referenced this issue

2026-05-05 10:21:55 -06:00

[PR #2802] [MERGED] Streamline redirect profiles #4535