[GH-ISSUE #57] Implement X11 isolation

gitea-mirror commented

2026-05-05 04:46:38 -06:00

Owner

Originally created by @ypid on GitHub (Sep 8, 2015).
Original GitHub issue: https://github.com/netblue30/firejail/issues/57

The problem: http://blog.invisiblethings.org/2011/04/23/linux-security-circus-on-gui-isolation.html

Possible solutions:

https://xpra.org (See also: https://github.com/subgraph/oz/wiki/Oz-Technical-Details)

Originally created by @ypid on GitHub (Sep 8, 2015). Original GitHub issue: https://github.com/netblue30/firejail/issues/57 The problem: http://blog.invisiblethings.org/2011/04/23/linux-security-circus-on-gui-isolation.html Possible solutions: - https://xpra.org (See also: https://github.com/subgraph/oz/wiki/Oz-Technical-Details)

gitea-mirror

2026-05-05 04:46:38 -06:00

closed this issue
added the
enhancement
label

gitea-mirror commented

2026-05-05 04:46:46 -06:00

Author

Owner

@ghost commented on GitHub (Sep 8, 2015):

Firejail can already be used to run a program in xpra, for example:
firejail xpra start :1 --start-child=xterm --no-daemon --exit-with-children
Then you can run xpra attach from another terminal to see the xterm.

It would certainly be possible to implement options in firejail that would make the process easier, for example spawning the xpra start and xpra attach in one command. I might have a play with this when I get some free time, or @netblue30 might have some ideas on how to do it better than me!

@ghost commented on GitHub (Sep 8, 2015): Firejail can already be used to run a program in xpra, for example: `firejail xpra start :1 --start-child=xterm --no-daemon --exit-with-children` Then you can run `xpra attach` from another terminal to see the xterm. It would certainly be possible to implement options in firejail that would make the process easier, for example spawning the `xpra start` and `xpra attach` in one command. I might have a play with this when I get some free time, or @netblue30 might have some ideas on how to do it better than me!

gitea-mirror commented

2026-05-05 04:46:49 -06:00

Author

Owner

@netblue30 commented on GitHub (Sep 8, 2015):

Thanks, it is a very good idea, I'll merge it when you are ready!

@netblue30 commented on GitHub (Sep 8, 2015): Thanks, it is a very good idea, I'll merge it when you are ready!

gitea-mirror commented

2026-05-05 04:46:52 -06:00

Author

Owner

@xmikos commented on GitHub (Sep 9, 2015):

Isn't there still .Xauthority file (firejail will copy it into sandbox even if you use --private)? There is no isolation, apps can still connect to hosts X server directly. Hosts X server have to be isolated more thoroughly, Xpra should be allowed to communicate with host only via one shared socket. Look how Oz is doing it...

@xmikos commented on GitHub (Sep 9, 2015): Isn't there still `.Xauthority` file (firejail will copy it into sandbox even if you use --private)? There is no isolation, apps can still connect to hosts X server directly. Hosts X server have to be isolated more thoroughly, Xpra should be allowed to communicate with host only via one shared socket. Look how [Oz](https://github.com/subgraph/oz) is doing it...

gitea-mirror commented

2026-05-05 04:46:56 -06:00

Author

Owner

@netblue30 commented on GitHub (Sep 10, 2015):

We'll make sure this doesn't happen, thanks.

@netblue30 commented on GitHub (Sep 10, 2015): We'll make sure this doesn't happen, thanks.

gitea-mirror commented

2026-05-05 04:46:59 -06:00

Author

Owner

@xmikos commented on GitHub (Nov 4, 2015):

Any news on this? Thanks

@xmikos commented on GitHub (Nov 4, 2015): Any news on this? Thanks

gitea-mirror commented

2026-05-05 04:47:02 -06:00

Author

Owner

@netblue30 commented on GitHub (Nov 4, 2015):

no

@netblue30 commented on GitHub (Nov 4, 2015): no

gitea-mirror commented

2026-05-05 04:47:05 -06:00

Author

Owner

@xmikos commented on GitHub (Nov 4, 2015):

Can you at least give us option to disable storing/copying of .Xauthority file?

@xmikos commented on GitHub (Nov 4, 2015): Can you at least give us option to disable storing/copying of .Xauthority file?

gitea-mirror commented

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

Author

Owner

@xmikos commented on GitHub (Nov 4, 2015):

It seems there are two places where you can find .Xauthority: ~/.Xauthority and /tmp/xauth-1000-_0 (you can find second location in XAUTHORITY env variable, it depends on UID and DISPLAY number).

@xmikos commented on GitHub (Nov 4, 2015): It seems there are two places where you can find .Xauthority: `~/.Xauthority` and `/tmp/xauth-1000-_0` (you can find second location in XAUTHORITY env variable, it depends on UID and DISPLAY number).

gitea-mirror commented

2026-05-05 04:47:10 -06:00

Author

Owner

@xmikos commented on GitHub (Nov 4, 2015):

I have also tried to blacklist access to X11 socket by adding this line to /etc/firejail/disable-common.inc:

blacklist /tmp/.X11-unix

But it doesn't work. Am I right that now I can't blacklist files/directories from /tmp? This is huge security hole. I have even tried to mount tmpfs over /tmp by using --tmpfs=/tmp option, but Firejail doesn't work at all with it.

@xmikos commented on GitHub (Nov 4, 2015): I have also tried to blacklist access to X11 socket by adding this line to `/etc/firejail/disable-common.inc`: ``` blacklist /tmp/.X11-unix ``` But it doesn't work. Am I right that now I can't blacklist files/directories from `/tmp`? This is huge security hole. I have even tried to mount tmpfs over /tmp by using `--tmpfs=/tmp` option, but Firejail doesn't work at all with it.

gitea-mirror commented

2026-05-05 04:47:13 -06:00

Author

Owner

@xmikos commented on GitHub (Nov 4, 2015):

Now this is strange... blacklisting actually works, if I look with file:///tmp/, I can't look into /tmp/.X11-unix, it really is blacklisted. But nevertheless X clients can still connect to host X server. It seems like UNIX sockets can still be used from inside of sandbox even if actual file is blacklisted? Dos anyone know what is actually happening?

@xmikos commented on GitHub (Nov 4, 2015): Now this is strange... blacklisting actually works, if I look with `file:///tmp/`, I can't look into `/tmp/.X11-unix`, it really is blacklisted. But nevertheless X clients can still connect to host X server. It seems like UNIX sockets can still be used from inside of sandbox even if actual file is blacklisted? Dos anyone know what is actually happening?

gitea-mirror commented

2026-05-05 04:47:16 -06:00

Author

Owner

@xmikos commented on GitHub (Nov 4, 2015):

I have found the actual problem, running ss -l, I see there are actually 2 sockets listening - normal UNIX socket and abstract UNIX socket:

u_str  LISTEN     0      128    @/tmp/.X11-unix/X0 10040                 * 0
u_str  LISTEN     0      128    /tmp/.X11-unix/X0 10041                 * 0

Blacklist is only blacklisting normal UNIX socket (pathname), but abstract socket is still accessible from sandbox. Is there some way how to blacklist abstract sockets in Firejail?

@xmikos commented on GitHub (Nov 4, 2015): I have found the actual problem, running `ss -l`, I see there are actually 2 sockets listening - normal UNIX socket and [abstract](http://man7.org/linux/man-pages/man7/unix.7.html) UNIX socket: ``` u_str LISTEN 0 128 @/tmp/.X11-unix/X0 10040 * 0 u_str LISTEN 0 128 /tmp/.X11-unix/X0 10041 * 0 ``` Blacklist is only blacklisting normal UNIX socket (pathname), but abstract socket is still accessible from sandbox. Is there some way how to blacklist abstract sockets in Firejail?

gitea-mirror commented

2026-05-05 04:47:18 -06:00

Author

Owner

@xmikos commented on GitHub (Nov 4, 2015):

It seems the only way how to limit access to abstract sockets (except of using SELinux, AppArmor or other LSM) is by using new network namespace. And of course firejail --net=none, firejail --net=br0 or similar really does work (I can't see abstract sockets in ss -l output inside sandbox anymore).

@xmikos commented on GitHub (Nov 4, 2015): It seems the only way how to limit access to abstract sockets (except of using SELinux, AppArmor or other LSM) is by using new network namespace. And of course `firejail --net=none`, `firejail --net=br0` or similar really does work (I can't see abstract sockets in `ss -l` output inside sandbox anymore).

gitea-mirror commented

2026-05-05 04:47:21 -06:00

Author

Owner

@netblue30 commented on GitHub (Nov 4, 2015):

Can you at least give us option to disable storing/copying of .Xauthority file?
It is already done for options such as --private and --whitelist. The version in the user home directory is preserved.

I see there are actually 2 sockets listening - normal UNIX socket and abstract UNIX socket:
The problem is you cannot stop an intruder to connect to the abstract socket. Xpra replaces the socket in /tmp/.X11 with its own socket.

@netblue30 commented on GitHub (Nov 4, 2015): > Can you at least give us option to disable storing/copying of .Xauthority file? > It is already done for options such as --private and --whitelist. The version in the user home directory is preserved. > > I see there are actually 2 sockets listening - normal UNIX socket and abstract UNIX socket: > The problem is you cannot stop an intruder to connect to the abstract socket. Xpra replaces the socket in /tmp/.X11 with its own socket.

gitea-mirror commented

2026-05-05 04:47:23 -06:00

Author

Owner

@xmikos commented on GitHub (Nov 4, 2015):

The problem is you cannot stop an intruder to connect to the abstract socket.

Yes you can, like I said in previous comment, network namespace isolates sandbox from abstract sockets on hosts. I have tried it and it really works.

@xmikos commented on GitHub (Nov 4, 2015): > The problem is you cannot stop an intruder to connect to the abstract socket. Yes you can, like I said in previous comment, network namespace isolates sandbox from abstract sockets on hosts. I have tried it and it really works.

gitea-mirror commented

2026-05-05 04:47:26 -06:00

Author

Owner

@netblue30 commented on GitHub (Nov 5, 2015):

Indeed, network ns seems to isolate abstract sockets. I was under the impression it doesn't!

@netblue30 commented on GitHub (Nov 5, 2015): Indeed, network ns seems to isolate abstract sockets. I was under the impression it doesn't!

gitea-mirror commented

2026-05-05 04:47:30 -06:00

Author

Owner

@ninja- commented on GitHub (Nov 13, 2015):

@netblue30 did it work for you with or without xpra?

@ninja- commented on GitHub (Nov 13, 2015): @netblue30 did it work for you with or without xpra?

gitea-mirror commented

2026-05-05 04:47:32 -06:00

Author

Owner

@netblue30 commented on GitHub (Nov 14, 2015):

I didn't try it with xpra, but without xpra X11 works fine because it picks up the regular Unix socket. I am using firefox all the time with --net=eth0, no problems.

@netblue30 commented on GitHub (Nov 14, 2015): I didn't try it with xpra, but without xpra X11 works fine because it picks up the regular Unix socket. I am using firefox all the time with --net=eth0, no problems.

gitea-mirror commented

2026-05-05 04:47:34 -06:00

Author

Owner

@ninja- commented on GitHub (Nov 14, 2015):

@netblue30 and that's enough to provide X11 isolation...?

@ninja- commented on GitHub (Nov 14, 2015): @netblue30 and that's enough to provide X11 isolation...?

gitea-mirror commented

2026-05-05 04:47:37 -06:00

Author

Owner

@xmikos commented on GitHub (Nov 14, 2015):

@ninja You have to blacklist regular unix socket too (/tmp/.X11-unix). Even better make whole /tmp private. I am writing wrapper script for running Xpra in sandbox, I will send link here when it will be done.

@xmikos commented on GitHub (Nov 14, 2015): @ninja You have to blacklist regular unix socket too (`/tmp/.X11-unix`). Even better make whole /tmp private. I am writing wrapper script for running Xpra in sandbox, I will send link here when it will be done.

gitea-mirror commented

2026-05-05 04:47:40 -06:00

Author

Owner

@netblue30 commented on GitHub (Nov 14, 2015):

@ninja- I think is enough for isolation.

@netblue30 commented on GitHub (Nov 14, 2015): @ninja- I think is enough for isolation.

gitea-mirror commented

2026-05-05 04:47:43 -06:00

Author

Owner

@netblue30 commented on GitHub (Jan 16, 2016):

More data in this discussion: https://github.com/netblue30/firejail/issues/229

@netblue30 commented on GitHub (Jan 16, 2016): More data in this discussion: https://github.com/netblue30/firejail/issues/229

gitea-mirror commented

2026-05-05 04:47:45 -06:00

Author

Owner

@ghost commented on GitHub (Jan 17, 2016):

Does xpra let the sandboxed application always view the clipboard? Does it let it capture the screen? I tend to view anything that has X access as potentially compromrising.

This was my approach: https://github.com/teran-mckinney/raru/blob/master/xraru

It's extremely hacky, but should be secure.

@ghost commented on GitHub (Jan 17, 2016): Does `xpra` let the sandboxed application always view the clipboard? Does it let it capture the screen? I tend to view anything that has X access as potentially compromrising. This was my approach: https://github.com/teran-mckinney/raru/blob/master/xraru It's extremely hacky, but should be secure.

gitea-mirror commented

2026-05-05 04:47:46 -06:00

Author

Owner

@netblue30 commented on GitHub (Jan 18, 2016):

I think xpra protects the clipboard and the screen - if I remember correctly, I played with it some time ago.

@netblue30 commented on GitHub (Jan 18, 2016): I think xpra protects the clipboard and the screen - if I remember correctly, I played with it some time ago.

gitea-mirror commented

2026-05-05 04:47:49 -06:00

Author

Owner

@ghost commented on GitHub (Jan 19, 2016):

Thank you! I'll play around with it in that case.

@ghost commented on GitHub (Jan 19, 2016): Thank you! I'll play around with it in that case.

gitea-mirror commented

2026-05-05 04:47:51 -06:00

Author

Owner

@netblue30 commented on GitHub (Jan 20, 2016):

Sure, let me know how is going. At some point I'll have to add full support for it - either xpra or some soket proxy.

@netblue30 commented on GitHub (Jan 20, 2016): Sure, let me know how is going. At some point I'll have to add full support for it - either xpra or some soket proxy.

gitea-mirror commented

2026-05-05 04:47:54 -06:00

Author

Owner

@genodeftest commented on GitHub (Jan 22, 2016):

I don't think real X11 isolation is even possible. How about using Wayland instead?

@genodeftest commented on GitHub (Jan 22, 2016): I don't think real X11 isolation is even possible. How about using Wayland instead?

gitea-mirror commented

2026-05-05 04:47:57 -06:00

Author

Owner

@netblue30 commented on GitHub (Jan 23, 2016):

Probably you are right, but Wayland is a long way out.

@netblue30 commented on GitHub (Jan 23, 2016): Probably you are right, but Wayland is a long way out.

gitea-mirror commented

2026-05-05 04:48:00 -06:00

Author

Owner

@genodeftest commented on GitHub (Jan 23, 2016):

Wayland will probably be default in Fedora 24 to be released in June 2016. With gnome-shell it's mostly usable since ~6 months. KDE Plasma is starting with wayland but has many crashers. Most other window managers aren't ported / porting to wayland (yet). I guess in ~2 years most distros released then will have wayland default. It's quite a long way, yes.

@genodeftest commented on GitHub (Jan 23, 2016): Wayland will probably be default in Fedora 24 to be released in June 2016. With gnome-shell it's mostly usable since ~6 months. KDE Plasma is starting with wayland but has many crashers. Most other window managers aren't ported / porting to wayland (yet). I guess in ~2 years most distros released then will have wayland default. It's quite a long way, yes.

gitea-mirror commented

2026-05-05 04:48:02 -06:00

Author

Owner

@ypid commented on GitHub (Jan 24, 2016):

@genodeftest Have you checked out how Qubes OS does X11 isolation? I think this is the best approach I have seen from a security point of view and the best thing, it is stable and you can use it today.

@xmikos You mentioned a script for using xpra with firejail. Do you have something ready you want to share?
I also started working on a wrapper script to do this: https://github.com/ypid/firejail-scripts

@ypid commented on GitHub (Jan 24, 2016): @genodeftest Have you checked out how [Qubes OS](https://www.qubes-os.org/) does X11 isolation? I think this is the best approach I have seen from a security point of view and the best thing, it is stable and you can use it today. @xmikos You [mentioned a script for using `xpra` with `firejail`](https://github.com/netblue30/firejail/issues/57#issuecomment-156689749). Do you have something ready you want to share? I also started working on a wrapper script to do this: https://github.com/ypid/firejail-scripts

gitea-mirror commented

2026-05-05 04:48:05 -06:00

Author

Owner

@skomorokh commented on GitHub (Jan 26, 2016):

In the interim, has anyone come up with a standard include file for keeping X away from non-X11 apps? From what I see from @xmikos 's work above, it's not necessarily a straightforward matter of blacklisting ~/.Xauthority

One thing I'd appreciate that for is the firejail shells I've been using to run nodejs stuff in---the package manager winds up executing thousands of scripts from not-particularly-audited sources.

@skomorokh commented on GitHub (Jan 26, 2016): In the interim, has anyone come up with a standard include file for keeping X away from non-X11 apps? From what I see from @xmikos 's work above, it's not necessarily a straightforward matter of blacklisting ~/.Xauthority One thing I'd appreciate that for is the firejail shells I've been using to run nodejs stuff in---the package manager winds up executing thousands of scripts from not-particularly-audited sources.

gitea-mirror commented

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

Author

Owner

@manevich commented on GitHub (Jan 27, 2016):

What about Xephyr that often mentioned in context of X11 isolation?
Is it worth looking on or have fatal problems?

@manevich commented on GitHub (Jan 27, 2016): What about [Xephyr](http://www.freedesktop.org/wiki/Software/Xephyr/) that often mentioned in context of X11 isolation? Is it worth looking on or have fatal problems?

gitea-mirror commented

2026-05-05 04:48:10 -06:00

Author

Owner

@netblue30 commented on GitHub (Jan 27, 2016):

@skomorokh

You look for X11 unix sockets and disable them:

$ netstat -a | grep X11
unix  2      [ ACC ]     STREAM     LISTENING     12796    /tmp/.X11-unix/X0
unix  2      [ ACC ]     STREAM     LISTENING     12795    @/tmp/.X11-unix/X0

The first one you blacklist (--blacklist=/tmp/.X11-unix) - actually you blacklist the whole directory. For the second one you need to create a new network namespace:

$ firejail --blacklist=/tmp/.X11-unix --net=eth0
Reading profile /etc/firejail/generic.profile
Reading profile /etc/firejail/disable-mgmt.inc
Reading profile /etc/firejail/disable-secret.inc
Reading profile /etc/firejail/disable-common.inc

** Note: you can use --noprofile to disable generic.profile **

Parent pid 14231, child pid 14232

Interface        MAC                IP               Mask             Status
lo                                  127.0.0.1        255.0.0.0        UP    
eth0-14231       aa:77:a9:76:5f:2b  192.168.1.117    255.255.255.0    UP    
Default gateway 192.168.1.1


Child process initialized
$ xterm
xterm: Xt error: Can't open display: :0.0
$

If you run a web server you also need to add an IP address for the sandbox (--ip=192.168.1.70), otherwise you end up with a random one like in the example above. If your program doesn't require network connectivity, or if you don't want to let it go outside on the network, change it to --net=none.

I don't have too much data, but Wikipedia has been running nodejs services under firejail for some time:

https://phabricator.wikimedia.org/search/query/UY4J9h1OSOJN/#R

@netblue30 commented on GitHub (Jan 27, 2016): @skomorokh You look for X11 unix sockets and disable them: ``` $ netstat -a | grep X11 unix 2 [ ACC ] STREAM LISTENING 12796 /tmp/.X11-unix/X0 unix 2 [ ACC ] STREAM LISTENING 12795 @/tmp/.X11-unix/X0 ``` The first one you blacklist (--blacklist=/tmp/.X11-unix) - actually you blacklist the whole directory. For the second one you need to create a new network namespace: ``` $ firejail --blacklist=/tmp/.X11-unix --net=eth0 Reading profile /etc/firejail/generic.profile Reading profile /etc/firejail/disable-mgmt.inc Reading profile /etc/firejail/disable-secret.inc Reading profile /etc/firejail/disable-common.inc ** Note: you can use --noprofile to disable generic.profile ** Parent pid 14231, child pid 14232 Interface MAC IP Mask Status lo 127.0.0.1 255.0.0.0 UP eth0-14231 aa:77:a9:76:5f:2b 192.168.1.117 255.255.255.0 UP Default gateway 192.168.1.1 Child process initialized $ xterm xterm: Xt error: Can't open display: :0.0 $ ``` If you run a web server you also need to add an IP address for the sandbox (--ip=192.168.1.70), otherwise you end up with a random one like in the example above. If your program doesn't require network connectivity, or if you don't want to let it go outside on the network, change it to --net=none. I don't have too much data, but Wikipedia has been running nodejs services under firejail for some time: https://phabricator.wikimedia.org/search/query/UY4J9h1OSOJN/#R

gitea-mirror commented

2026-05-05 04:48:11 -06:00

Author

Owner

@netblue30 commented on GitHub (Feb 27, 2016):

I added xpra support, based on @pmillerchip idea above. Thanks!

@netblue30 commented on GitHub (Feb 27, 2016): I added xpra support, based on @pmillerchip idea above. Thanks!

gitea-mirror commented

2026-05-05 04:48:13 -06:00

Author

Owner

@NodeGuy commented on GitHub (Dec 9, 2016):

Could this be solved more simply using the X11 Security Extension?

@NodeGuy commented on GitHub (Dec 9, 2016): Could this be solved more simply using the [X11 Security Extension](https://notehub.org/rp5n2)?

gitea-mirror commented

2026-05-05 04:48:15 -06:00

Author

Owner

@the8472 commented on GitHub (Dec 9, 2016):

@NodeGuy isn't that what was implemented with 0579100e2d ?

@the8472 commented on GitHub (Dec 9, 2016): @NodeGuy isn't that what was implemented with 0579100e2df9b9af899a7143ff1dd2511ca226c1 ?

gitea-mirror commented

2026-05-05 04:48:16 -06:00

Author

Owner

@netblue30 commented on GitHub (Dec 10, 2016):

It is already implemented, try it out:

$ firejail --x11=xorg firefox

@netblue30 commented on GitHub (Dec 10, 2016): It is already implemented, try it out: ````` $ firejail --x11=xorg firefox `````

gitea-mirror commented

2026-05-05 04:48:18 -06:00

Author

Owner

@ssokolow commented on GitHub (Dec 10, 2016):

Huh. I wonder whether the X11 Security Extension had any input into the design of XWayland's security model or whether it's just purely a nested, rootless X server which enforces a bit more policy. (eg. They only just added support to Weston for not ignoring -geometry +x+y to un-break certain old applications which are so stupidly fragile that they somehow rely on it.)

@ssokolow commented on GitHub (Dec 10, 2016): Huh. I wonder whether the X11 Security Extension had any input into the design of XWayland's security model or whether it's just purely a nested, rootless X server which enforces a bit more policy. (eg. They [only just added](http://www.phoronix.com/scan.php?page=news_item&px=XWayland-Window-Positioning) support to Weston for not ignoring `-geometry +x+y` to un-break certain old applications which are so stupidly fragile that they somehow rely on it.)

gitea-mirror commented

2026-05-05 04:48:21 -06:00

Author

Owner

@djfd commented on GitHub (Dec 11, 2016):

Wondering if --x11=xorg works at all

simply running xterm via firejail --x11=xorg xterm I am still able to catch anything with xinput test kbd-num... (I disabled blacklisting of xinput for a test time, just FYI)

while running it as described here produces exactly that I am expecting to get:

./untr.sh xterm
xterm: warning, error event received:
X Error of failed request:  BadAccess (attempt to access private resource denied)
  Major opcode of failed request:  104 (X_Bell)
  Serial number of failed request:  556
  Current serial number in output stream:  557

what did I miss?

And one more question. Why proifiles are built as all-permitted-if-not-prohibitted? is there way to use reverse approach for a better security, ie. reject all that was not explicitly permitted? perhaps some startup key that I did miss?

@djfd commented on GitHub (Dec 11, 2016): Wondering if ```--x11=xorg``` works at all simply running xterm via ```firejail --x11=xorg xterm``` I am still able to catch anything with ```xinput test kbd-num```... (I disabled blacklisting of xinput for a test time, just FYI) while running it [as described here](https://notehub.org/rp5n2) produces exactly that I am expecting to get: ``` ./untr.sh xterm xterm: warning, error event received: X Error of failed request: BadAccess (attempt to access private resource denied) Major opcode of failed request: 104 (X_Bell) Serial number of failed request: 556 Current serial number in output stream: 557 ``` what did I miss? And one more question. Why proifiles are built as `all-permitted-if-not-prohibitted`? is there way to use reverse approach for a better security, ie. reject all that was not explicitly permitted? perhaps some startup key that I did miss?

gitea-mirror commented

2026-05-05 04:48:23 -06:00

Author

Owner

@netblue30 commented on GitHub (Dec 11, 2016):

Wondering if --x11=xorg works at all

I cannot get xterm to work this way on Debian stable, although people on unstable say they fixed xterm and now is working.

I am still able to catch anything with xinput test kbd-num... (I disabled blacklisting of xinput for a test time, just FYI)

How do you run it?

Why proifiles are built as all-permitted-if-not-prohibitted

Historically, it was easier to build them this way. We are moving to a whitelisted model, the browsers are already done.

@netblue30 commented on GitHub (Dec 11, 2016): > Wondering if --x11=xorg works at all I cannot get xterm to work this way on Debian stable, although people on unstable say they fixed xterm and now is working. > I am still able to catch anything with xinput test kbd-num... (I disabled blacklisting of xinput for a test time, just FYI) How do you run it? > Why proifiles are built as all-permitted-if-not-prohibitted Historically, it was easier to build them this way. We are moving to a whitelisted model, the browsers are already done.

gitea-mirror commented

2026-05-05 04:48:26 -06:00

Author

Owner

@djfd commented on GitHub (Dec 11, 2016):

hmm, I run it just by typing (in gnome-terminal, if it does matter)
firejail --x11=xorg xterm
this opens xterm window. In there I type
xinput list
to see my kbd id, then
xinput test 11
switch back to original terminal and typing there anything I can see these codes in xterm window

firejail version 0.9.44.2
xterm -v gives XTerm(327)
Linux my-arch 4.8.12-3-ARCH #1 SMP PREEMPT Thu Dec 8 16:10:23 CET 2016 x86_64 GNU/Linux
that is it

UPD. Xorg/gdm/mutter are X server, display and window manager
UPD2. There is not user namespaces in arch kernels, can this be a reason?

as for moving to whitelisted model, it is right direction move, I suppose. Thank you for the information!

@djfd commented on GitHub (Dec 11, 2016): hmm, I run it just by typing (in gnome-terminal, if it does matter) ```firejail --x11=xorg xterm``` this opens xterm window. In there I type ```xinput list``` to see my kbd id, then ```xinput test 11``` switch back to original terminal and typing there anything I can see these codes in xterm window firejail version 0.9.44.2 ```xterm -v``` gives XTerm(327) ```Linux my-arch 4.8.12-3-ARCH #1 SMP PREEMPT Thu Dec 8 16:10:23 CET 2016 x86_64 GNU/Linux``` that is it **UPD**. Xorg/gdm/mutter are X server, display and window manager **UPD2**. There is not user namespaces in arch kernels, can this be a reason? as for moving to whitelisted model, it is right direction move, I suppose. Thank you for the information!

gitea-mirror commented

2026-05-05 04:48:29 -06:00

Author

Owner

@genodeftest commented on GitHub (Dec 11, 2016):

Real X11 isolation can only work if you run it inside its own XWayland instance. You might try to get this by running firejail within a XWayland-enabled weston instance.

@djfd : Why would arch kernels not have user namespaces? I doubt they can run systemd without user namespaces.

@genodeftest commented on GitHub (Dec 11, 2016): Real X11 isolation can only work if you run it inside its own XWayland instance. You might try to get this by running firejail within a XWayland-enabled weston instance. @djfd : Why would arch kernels not have user namespaces? I doubt they can run systemd without user namespaces.

gitea-mirror commented

2026-05-05 04:48:32 -06:00

Author

Owner

@djfd commented on GitHub (Dec 11, 2016):

yeah, I know about wayland. unfortunately it is still too raw (for me) to be used as a host environment, thus Xorg for now. as an isolation box... well, is not very good too, I do not need to see entire weston box with an orphan single app floating there (for this exact case), just need a single app window. for now the only way that works for me is xpra, ie. --x11=xpra.

I would prefer --x11=xorg instead, but this way it somewhy does not work...

As for user namespaces in arch linux, they refer to this bug in firejail docs

UPD
@netblue30 Could you please add some delay (or maybe a parameter) to delay isolated app when starting up zephyr or xpra? with xpra-1.0 there is some delay when starting separate server, attaching the client fails then because it cannot find the server to connect to... Or maybe just silently wait until server init completed, then try to attach...

@djfd commented on GitHub (Dec 11, 2016): yeah, I know about wayland. unfortunately it is still too raw (for me) to be used as a host environment, thus Xorg for now. as an isolation box... well, is not very good too, I do not need to see entire weston box with an orphan single app floating there (for this exact case), just need a single app window. for now the only way that works for me is xpra, ie. ```--x11=xpra```. I would prefer ```--x11=xorg``` instead, but this way it somewhy does not work... As for user namespaces in arch linux, they refer to [this bug](https://bugs.archlinux.org/task/36969) in [firejail docs](https://wiki.archlinux.org/index.php/Firejail) **UPD** @netblue30 Could you please add some delay (or maybe a parameter) to delay isolated app when starting up zephyr or xpra? with xpra-1.0 there is some delay when starting separate server, attaching the client fails then because it cannot find the server to connect to... Or maybe just silently wait until server init completed, then try to attach...

gitea-mirror commented

2026-05-05 04:48:35 -06:00

Author

Owner

@netblue30 commented on GitHub (Dec 14, 2016):

xterm is broken, it uses one of the extensions disabled by X11 Security Extension. It ends up crashing, at different moments depending on the version of xterm. I assume Arch started compiling it without the support for X11 Security Extension, so if you see xterm working it means X11 Security Extension didn't take effect. I am still using xterm on Debian stable, but as soon as I select something with the mouse, it goes down in flames.

Firejail detects automatically the presence of user namespace in the kernel. On Arch it will not attempt to initialize it. So far it worked fine, it doesn't seem to interfere with anything else.

Added a 1 second delay after starting xpra server, we can bump it up if necesssary. Give it a try. Thanks.

@netblue30 commented on GitHub (Dec 14, 2016): xterm is broken, it uses one of the extensions disabled by X11 Security Extension. It ends up crashing, at different moments depending on the version of xterm. I assume Arch started compiling it without the support for X11 Security Extension, so if you see xterm working it means X11 Security Extension didn't take effect. I am still using xterm on Debian stable, but as soon as I select something with the mouse, it goes down in flames. Firejail detects automatically the presence of user namespace in the kernel. On Arch it will not attempt to initialize it. So far it worked fine, it doesn't seem to interfere with anything else. Added a 1 second delay after starting xpra server, we can bump it up if necesssary. Give it a try. Thanks.

gitea-mirror commented

2026-05-05 04:48:37 -06:00

Author

Owner

@djfd commented on GitHub (Dec 14, 2016):

If xterm does not have security extension support then why it is crashed [as expected] if I simply run it by hands and failed to do so when launched by firejail?

If you need some logging just let me know

@djfd commented on GitHub (Dec 14, 2016): If xterm does not have security extension support then why it is crashed [as expected] if I simply run it by hands and failed to do so when launched by firejail? If you need some logging just let me know

gitea-mirror commented

2026-05-05 04:48:39 -06:00

Author

Owner

@netblue30 commented on GitHub (Dec 15, 2016):

I have no idea what they do, just guessing, but is obvious they don't support the security extension, They don't recover nicely when the security extension is enabled, instead they just crush.

@netblue30 commented on GitHub (Dec 15, 2016): I have no idea what they do, just guessing, but is obvious they don't support the security extension, They don't recover nicely when the security extension is enabled, instead they just crush.

gitea-mirror commented

2026-05-05 04:48:43 -06:00

Author

Owner

@NodeGuy commented on GitHub (Dec 19, 2016):

@NodeGuy isn't that what was implemented with 0579100 ?

Yes, I wasn't aware of that. Thanks for pointing it out.

@NodeGuy commented on GitHub (Dec 19, 2016): > @NodeGuy isn't that what was implemented with 0579100 ? Yes, I wasn't aware of that. Thanks for pointing it out.

gitea-mirror commented

2026-05-05 04:48:46 -06:00

Author

Owner

@vporton commented on GitHub (Apr 4, 2021):

We'll make sure this doesn't happen, thanks.

~/.Xauthority is still copied into --private current dir!!

You cause more insecurity than security!!

Fix it!!

firejail version 0.9.62.4

@vporton commented on GitHub (Apr 4, 2021): > We'll make sure this doesn't happen, thanks. `~/.Xauthority` is *still* copied into `--private` current dir!! You cause more insecurity than security!! Fix it!! firejail version 0.9.62.4

gitea-mirror commented

2026-05-05 04:48:50 -06:00

Author

Owner

@vporton commented on GitHub (Apr 4, 2021):

We'll make sure this doesn't happen, thanks.

~/.Xauthority is still copied into --private current dir!!

You cause more insecurity than security!!

Fix it!!

firejail version 0.9.62.4

Oh, it did happen with some unknown weird options I possibly passed. Need to investigate these insecure arguments.

@vporton commented on GitHub (Apr 4, 2021): > > We'll make sure this doesn't happen, thanks. > > `~/.Xauthority` is _still_ copied into `--private` current dir!! > > You cause more insecurity than security!! > > Fix it!! > > firejail version 0.9.62.4 Oh, it did happen with some unknown weird options I possibly passed. Need to investigate these insecure arguments.

gitea-mirror referenced this issue

2026-05-05 10:02:49 -06:00

[PR #29] [MERGED] Replace get_link with realpath #3513

Rows
Columns

[GH-ISSUE #57] Implement X11 isolation #29