[GH-ISSUE #2205] Program in X11 sandbox can kill host X session

gitea-mirror commented

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

Owner

Originally created by @iskunk on GitHub (Oct 18, 2018).
Original GitHub issue: https://github.com/netblue30/firejail/issues/2205

In testing Firejail with Openbox, I found a rather dismaying issue. (I have verified that this occurs with Git d0a8395d, the current revision as of this writing.)

Start up Openbox in an X11 sandbox like so:

firejail --x11=xephyr --net=eth0 openbox

Right-click to bring up the WM menu, select "Exit", and confirm.

Not only does the Openbox-in-Xephyr session go away, the entire host X session [in which you started up Firejail in the first place] goes away. (I obtained this result with the Xfce desktop running on Ubuntu 18.04/bionic.)

And if a sandboxed Openbox can kill your login session, then any sandboxed (X11) program can kill your login session.

For what it's worth, this does not occur if you use whitelist or private.

Originally created by @iskunk on GitHub (Oct 18, 2018). Original GitHub issue: https://github.com/netblue30/firejail/issues/2205 In testing Firejail with Openbox, I found a rather dismaying issue. (I have verified that this occurs with Git d0a8395d, the current revision as of this writing.) Start up Openbox in an X11 sandbox like so: ``` firejail --x11=xephyr --net=eth0 openbox ``` Right-click to bring up the WM menu, select "Exit", and confirm. Not only does the Openbox-in-Xephyr session go away, the entire host X session [in which you started up Firejail in the first place] goes away. (I obtained this result with the Xfce desktop running on Ubuntu 18.04/bionic.) And if a sandboxed Openbox can kill your login session, then any sandboxed (X11) program can kill your login session. For what it's worth, this does not occur if you use `whitelist` or `private`.

gitea-mirror

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

closed this issue
added the
bug
label

gitea-mirror commented

2026-05-05 08:08:39 -06:00

Author

Owner

@reinerh commented on GitHub (Oct 19, 2018):

I can't reproduce it. I started firejail --x11=xephyr openbox inside awesome-wm, and exited openbox via its right-click menu, but my outer X session stayed active.

@reinerh commented on GitHub (Oct 19, 2018): I can't reproduce it. I started `firejail --x11=xephyr openbox` inside awesome-wm, and exited openbox via its right-click menu, but my outer X session stayed active.

gitea-mirror commented

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

Author

Owner

@iskunk commented on GitHub (Oct 19, 2018):

It probably has to do with how the host WM/desktop manages its session, which is why I mentioned that this occurred with Xfce. Openbox is probably sending some sort of semi-standard "end session" message, which Xfce interpreted, but perhaps awesome-wm does not.

@iskunk commented on GitHub (Oct 19, 2018): It probably has to do with how the host WM/desktop manages its session, which is why I mentioned that this occurred with Xfce. Openbox is probably sending some sort of semi-standard "end session" message, which Xfce interpreted, but perhaps awesome-wm does not.

gitea-mirror commented

2026-05-05 08:08:41 -06:00

Author

Owner

@rusty-snake commented on GitHub (May 14, 2019):

@iskunk maybe firejail --nodbus --x11=xephyr openbox works.

@rusty-snake commented on GitHub (May 14, 2019): @iskunk maybe `firejail --nodbus --x11=xephyr openbox` works.

gitea-mirror commented

2026-05-05 08:08:43 -06:00

Author

Owner

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

@iskunk Is this still an issue?

@chiraag-nataraj commented on GitHub (May 21, 2019): @iskunk Is this still an issue?

gitea-mirror commented

2026-05-05 08:08:44 -06:00

Author

Owner

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

I'll go ahead and close this for now. @iskunk, please feel free to re-open if you still have this issue or have further questions.

@chiraag-nataraj commented on GitHub (May 23, 2019): I'll go ahead and close this for now. @iskunk, please feel free to re-open if you still have this issue or have further questions.

gitea-mirror commented

2026-05-05 08:08:44 -06:00

Author

Owner

@iskunk commented on GitHub (May 23, 2019):

Hi @chiraag-nataraj, apologies for the delay; I had to rebuild a test environment for this bug.

I tried this again, using firejail 0.9.60~rc2 (Git 43cbc6d5), and have verified that the issue still exists. The host X session remains vulnerable to a sandboxed X11 program.

I also tested with --nodbus, as @rusty-snake suggested. Unfortunately, this option did not improve matters.

(I cannot re-open this bug.)

@iskunk commented on GitHub (May 23, 2019): Hi @chiraag-nataraj, apologies for the delay; I had to rebuild a test environment for this bug. I tried this again, using firejail `0.9.60~rc2` (Git `43cbc6d5`), and have verified that the issue still exists. The host X session remains vulnerable to a sandboxed X11 program. I also tested with `--nodbus`, as @rusty-snake suggested. Unfortunately, this option did not improve matters. (I cannot re-open this bug.)

gitea-mirror commented

2026-05-05 08:08:45 -06:00

Author

Owner

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

Reopening!

@chiraag-nataraj commented on GitHub (May 23, 2019): Reopening!

gitea-mirror commented

2026-05-05 08:08:45 -06:00

Author

Owner

@rusty-snake commented on GitHub (May 23, 2019):

@iskunk can you try firejail --net=none --nonewprivs --nodbus --private --ipc-namespace --nogroups --shell=none --private-tmp --private-bin=openbox --private-etc=none --x11=xephyr openbox. If one (or more) of this args break openbox to start, try without this one.

@rusty-snake commented on GitHub (May 23, 2019): @iskunk can you try `firejail --net=none --nonewprivs --nodbus --private --ipc-namespace --nogroups --shell=none --private-tmp --private-bin=openbox --private-etc=none --x11=xephyr openbox`. If one (or more) of this args break openbox to start, try without this one.

gitea-mirror commented

2026-05-05 08:08:46 -06:00

Author

Owner

@iskunk commented on GitHub (May 23, 2019):

@rusty-snake, I had to drop --private-bin and --private-etc for Openbox to start, but with the remaining options, the session was not killed.

I then proceeded to remove options (except for --x11, of course) until I observed the host X session killed as originally reported.

The --private option appears to be significant. That one prevents the problem behavior. (Specifically, firejail --private --x11=xephyr openbox is good.)

That is not the only one, however. After further testing, I confirmed that firejail --net=none --private-tmp --x11=xephyr openbox does not exhibit the problem either. But if I remove either the --net or the --private-tmp, the problem returns.

Note that my test environment is an Xfce (Xubuntu) host X session with a default Openbox session in the sandbox, running on a VM. This issue should not be difficult to reproduce.

@iskunk commented on GitHub (May 23, 2019): @rusty-snake, I had to drop `--private-bin` and `--private-etc` for Openbox to start, but with the remaining options, the session was not killed. I then proceeded to remove options (except for `--x11`, of course) until I observed the host X session killed as originally reported. The `--private` option appears to be significant. That one prevents the problem behavior. (Specifically, `firejail --private --x11=xephyr openbox` is good.) That is not the only one, however. After further testing, I confirmed that `firejail --net=none --private-tmp --x11=xephyr openbox` does not exhibit the problem either. But if I remove either the `--net` or the `--private-tmp`, the problem returns. Note that my test environment is an Xfce (Xubuntu) host X session with a default Openbox session in the sandbox, running on a VM. This issue should not be difficult to reproduce.

gitea-mirror commented

2026-05-05 08:08:46 -06:00

Author

Owner

@rusty-snake commented on GitHub (Jun 24, 2019):

@iskunk sorry for later responding, but now I have found a solution:
firejail --blacklist=${HOME}/.ICEauthority --x11=xephyr openbox

@rusty-snake commented on GitHub (Jun 24, 2019): @iskunk sorry for later responding, but now I have found a solution: `firejail --blacklist=${HOME}/.ICEauthority --x11=xephyr openbox`

gitea-mirror commented

2026-05-05 08:08:46 -06:00

Author

Owner

@iskunk commented on GitHub (Jun 24, 2019):

@rusty-snake: Confirmed that blacklisting ~/.ICEauthority prevents the issue.

The various --x11 modes should probably include that one in their blacklisting, yes? The issue of a sandboxed environment killing the host X session is surely unexpected.

@iskunk commented on GitHub (Jun 24, 2019): @rusty-snake: Confirmed that blacklisting `~/.ICEauthority` prevents the issue. The various `--x11` modes should probably include that one in their blacklisting, yes? The issue of a sandboxed environment killing the host X session is surely unexpected.

gitea-mirror commented

2026-05-05 08:08:47 -06:00

Author

Owner

@rusty-snake commented on GitHub (Jun 25, 2019):

Because it must be added to the openbox profile, but only when --x11 is present, I see three options:

add it with a comment to openbox and other affected WMs
add it to the documentation (1, 2)
--x11 implieds blacklist ${HOME}/.ICEauthority

@rusty-snake commented on GitHub (Jun 25, 2019): Because it must be added to the openbox profile, but only when --x11 is present, I see three options: 1. add it with a comment to openbox and other affected WMs 2. add it to the documentation ([1], [2]) 3. `--x11` implieds `blacklist ${HOME}/.ICEauthority` [1]: https://firejail.wordpress.com/documentation-2/x11-guide/ [2]: https://firejail.wordpress.com/documentation-2/basic-usage/#x11

gitea-mirror commented

2026-05-05 08:08:47 -06:00

Author

Owner

@iskunk commented on GitHub (Jun 25, 2019):

I would think #3 is the best option, for the following reasons:

This is not just a matter of (known) WMs possibly ending the session; badly-written programs, or even a hostile program may do this
The failure mode (loss of an X session, with associated potential for data loss) makes it a bit more serious of a threat than can reasonably be addressed in documentation
--x11 already blacklists relevant files like ~/.Xauthority; this would only be adding to that, rather than being an entirely new behavior

@iskunk commented on GitHub (Jun 25, 2019): I would think #3 is the best option, for the following reasons: * This is not just a matter of (known) WMs possibly ending the session; badly-written programs, or even a hostile program may do this * The failure mode (loss of an X session, with associated potential for data loss) makes it a bit more serious of a threat than can reasonably be addressed in documentation * `--x11` already blacklists relevant files like `~/.Xauthority`; this would only be adding to that, rather than being an entirely new behavior

gitea-mirror commented

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

Author

Owner

@rusty-snake commented on GitHub (Jun 25, 2019):

With #3 you link to an issue 😁

I also think that the 3. option the best solution is, if you hate the necessary C knowledge, you are welcome to open a PR, I can' t (yet) write C 😢 .

@rusty-snake commented on GitHub (Jun 25, 2019): _With `#3` you link to an issue :grin:_ I also think that the 3. option the best solution is, if you hate the necessary C knowledge, you are welcome to open a PR, I can' t (yet) write C :cry: .

gitea-mirror commented

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

Author

Owner

@iskunk commented on GitHub (Jun 26, 2019):

Oh, nuts, didn't notice that :-]

I looked in the code. I can find where to add blacklisting for --x11=none, but the other cases are a bit less straightforward. There's a lot of special handling for ~/.Xauthority, for example.

I did figure that the /tmp/.ICE-unix/ socket directory should probably also be blocked by default in a sandboxed session. (I can't find a ready-made frontend program that demonstrates this, but it is theoretically possible that a misbehaving non-X program could make use of libICE to send an unwanted "end session" message.)

@iskunk commented on GitHub (Jun 26, 2019): Oh, nuts, didn't notice that :-] I looked in the code. I can find where to add blacklisting for `--x11=none`, but the other cases are a bit less straightforward. There's a lot of special handling for `~/.Xauthority`, for example. I did figure that the `/tmp/.ICE-unix/` socket directory should probably also be blocked by default in a sandboxed session. (I can't find a ready-made frontend program that demonstrates this, but it is theoretically possible that a misbehaving non-X program could make use of libICE to send an unwanted "end session" message.)

gitea-mirror commented

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

Author

Owner

@rusty-snake commented on GitHub (Jun 27, 2019):

private-tmp prenvents access to /tmp/.ICE-unix, but if a profile not has it …

@rusty-snake commented on GitHub (Jun 27, 2019): `private-tmp` prenvents access to `/tmp/.ICE-unix`, but if a profile not has it …

gitea-mirror commented

2026-05-05 08:08:49 -06:00

Author

Owner

@iskunk commented on GitHub (Jun 28, 2019):

Yeah, that explains why --private-tmp made the issue go away (as well as --private with ~/.ICEauthority).

This does seem somewhat urgent as the authentication needed to mess with the X session is separate from XAUTHORITY; i.e. blocking that one does not protect the session.

Should we pull in netblue30? I don't think a fix for this should be complicated; it's mainly knowing where the blocking bits need to go...

@iskunk commented on GitHub (Jun 28, 2019): Yeah, that explains why `--private-tmp` made the issue go away (as well as `--private` with `~/.ICEauthority`). This does seem somewhat urgent as the authentication needed to mess with the X session is separate from `XAUTHORITY`; i.e. blocking that one does not protect the session. Should we pull in **netblue30**? I don't think a fix for this should be complicated; it's mainly knowing where the blocking bits need to go...

gitea-mirror commented

2026-05-05 08:08:49 -06:00

Author

Owner

@chiraag-nataraj commented on GitHub (Sep 16, 2019):

@netblue30 and others, we should put this fix in...

@chiraag-nataraj commented on GitHub (Sep 16, 2019): @netblue30 and others, we should put this fix in...

gitea-mirror commented

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

Author

Owner

@smitsohu commented on GitHub (Oct 2, 2019):

I did figure that the /tmp/.ICE-unix/ socket directory should probably also be blocked by default in a sandboxed session.

I tend to agree. I would suggest to mount a tmpfs on this directory, so that just in case a program wants to talk to other programs in the same sandbox using whatever ICE based protocol, it is still able to do so.

But there is one problem, maybe two. First, in the case of session managers the sockets often seem to be no real files but in the abstract namespace (same as the sockets in /tmp/.X11-unix). This means a tmpfs (or a blacklist) is not effective in all cases, we need one of the net options to always and reliably shut down the access. So one "solution" might be to indeed align this feature with the x11 options (thematically).

Second, I'm a little bit worried if programs both inside and outside sandboxes all write to the same cookie database (aka ~/.ICEauthority). The sockets in /tmp/.ICE-unix are named after the pid of the process that created them, so if there are two or many pid namespaces, there could be a risk of file name collisions. Maybe Firejail should take care each sandbox has their own .ICEauthority file by setting an ICEAUTHORITY environment variable accordingly?

Is this overkill? Other ideas?

@smitsohu commented on GitHub (Oct 2, 2019): > I did figure that the /tmp/.ICE-unix/ socket directory should probably also be blocked by default in a sandboxed session. I tend to agree. I would suggest to mount a tmpfs on this directory, so that just in case a program wants to talk to other programs in the same sandbox using whatever ICE based protocol, it is still able to do so. But there is one problem, maybe two. First, in the case of session managers the sockets often seem to be no real files but in the abstract namespace (same as the sockets in /tmp/.X11-unix). This means a tmpfs (or a blacklist) is not effective in all cases, we need one of the `net` options to always and reliably shut down the access. So one "solution" might be to indeed align this feature with the `x11` options (thematically). Second, I'm a little bit worried if programs both inside and outside sandboxes all write to the same cookie database (aka ~/.ICEauthority). The sockets in /tmp/.ICE-unix are named after the pid of the process that created them, so if there are two or many pid namespaces, there could be a risk of file name collisions. Maybe Firejail should take care each sandbox has their own .ICEauthority file by setting an ICEAUTHORITY environment variable accordingly? Is this overkill? Other ideas?

gitea-mirror commented

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

Author

Owner

@smitsohu commented on GitHub (Oct 2, 2019):

The sockets in /tmp/.ICE-unix are named after the pid of the process that created them, so if there are two or many pid namespaces, there could be a risk of file name collisions.

On the other hand, people are provoking similar situations with private-tmp already now, and there seem to be no reported problems.

@smitsohu commented on GitHub (Oct 2, 2019): > The sockets in /tmp/.ICE-unix are named after the pid of the process that created them, so if there are two or many pid namespaces, there could be a risk of file name collisions. On the other hand, people are provoking similar situations with `private-tmp` already now, and there seem to be no reported problems.

gitea-mirror commented

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

Author

Owner

@iskunk commented on GitHub (Oct 3, 2019):

My experience to date with private-tmp is that programs sometimes complain with a message like "cannot connect to session manager." This would likewise happen if ICE is blocked.

It's not a showstopper for most X11 applications, and unless people are running e.g. full GNOME desktops within Firejail and complaining that they can't save their sessions properly, I don't think there's a pressing need to provide a separate instance of ICE et al. within an X11 sandbox.

@iskunk commented on GitHub (Oct 3, 2019): My experience to date with `private-tmp` is that programs sometimes complain with a message like "cannot connect to session manager." This would likewise happen if ICE is blocked. It's not a showstopper for most X11 applications, and unless people are running e.g. full GNOME desktops within Firejail and complaining that they can't save their sessions properly, I don't think there's a pressing need to provide a separate instance of ICE et al. within an X11 sandbox.

gitea-mirror commented

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

Author

Owner

@smitsohu commented on GitHub (Oct 4, 2019):

Or maybe this is too complicated thinking. Should we just add a blacklist ${HOME}/.ICEauthority to disable-common.inc?

@smitsohu commented on GitHub (Oct 4, 2019): Or maybe this is too complicated thinking. Should we just add a `blacklist ${HOME}/.ICEauthority` to disable-common.inc?

gitea-mirror commented

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

Author

Owner

@smitsohu commented on GitHub (Oct 7, 2019):

Alright, proposing a new ?HAS_X11 conditional, and putting the blacklist in disable-common.inc. Will put a fix in the next few days.

@smitsohu commented on GitHub (Oct 7, 2019): Alright, proposing a new `?HAS_X11` conditional, and putting the blacklist in disable-common.inc. Will put a fix in the next few days.

gitea-mirror commented

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

Author

Owner

@smitsohu commented on GitHub (Oct 8, 2019):

Oops. x11 xorg is not covered by the conditional, I'll have to add that option, too.

@smitsohu commented on GitHub (Oct 8, 2019): Oops. `x11 xorg` is not covered by the conditional, I'll have to add that option, too.

gitea-mirror commented

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

Author

Owner

@rusty-snake commented on GitHub (Oct 8, 2019):

for more flexibility in the future something like that would be helpful

?HAS(<LINE>): <LINE>
?HAS(seccomp): blacklist /...
?HAS(net none): x11 none

@rusty-snake commented on GitHub (Oct 8, 2019): for more flexibility in the future something like that would be helpful ``` ?HAS(<LINE>): <LINE> ?HAS(seccomp): blacklist /... ?HAS(net none): x11 none ```

gitea-mirror commented

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

Author

Owner

@smitsohu commented on GitHub (Oct 9, 2019):

?HAS(net none):

How about something like ?HAS_NET ?

It tends to have influence on various other options...

That doesn't exclude e.g. ?HAS_NETNONE of course.

@smitsohu commented on GitHub (Oct 9, 2019): > ?HAS(net none): How about something like `?HAS_NET` ? It tends to have influence on various other options... That doesn't exclude e.g. `?HAS_NETNONE` of course.

gitea-mirror commented

2026-05-05 08:08:53 -06:00

Author

Owner

@rusty-snake commented on GitHub (Oct 9, 2019):

Sure, HAS_NET or similar isn't bad, but my idea was more about conditions by line match (like ignore).

@rusty-snake commented on GitHub (Oct 9, 2019): Sure, `HAS_NET` or similar isn't bad, but my idea was more about conditions by line match (like `ignore`).

gitea-mirror commented

2026-05-05 08:08:53 -06:00

Author

Owner

@smitsohu commented on GitHub (Nov 11, 2019):

I'll add HAS_NET for the moment as it is useful and a particularly low hanging fruit :)

@smitsohu commented on GitHub (Nov 11, 2019): I'll add `HAS_NET` for the moment as it is useful and a particularly low hanging fruit :)

gitea-mirror commented

2026-05-05 08:08:53 -06:00

Author

Owner

@matu3ba commented on GitHub (Sep 9, 2020):

@smitsohu What is the status on this? Closing?

@matu3ba commented on GitHub (Sep 9, 2020): @smitsohu What is the status on this? Closing?

Rows
Columns

[GH-ISSUE #2205] Program in X11 sandbox can kill host X session #1478