Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Odd behaviour with --x11=xorg under GNOME 3 / gdm #1652

Open
sakaki- opened this issue Nov 17, 2017 · 3 comments
Open

Odd behaviour with --x11=xorg under GNOME 3 / gdm #1652

sakaki- opened this issue Nov 17, 2017 · 3 comments
Labels
enhancement New feature request

Comments

@sakaki-
Copy link

sakaki- commented Nov 17, 2017

Hi, as I mentioned in #1600 I am putting together an addition to my EFI Install Guide regarding the use of an X11-sandboxed (Xephyr) sandbox for use with firefox.

I now have a configuration that works even with WiFi interfaces, using the bridge configuration suggested your answer to #1600, so thanks for that.

However, having read about the --x11=xorg option in the firejail manpage, I thought I'd give that a try too, since it would be much simpler to setup for most users. I recompiled my X server using the xcsecurity USE flag (I use Gentoo), restarted, and then tried to see if e.g. xinput would be blocked from scanning keyboard input when untrusted, as it should be. However, starting bash under the firefox profile with --x11=xorg did not give the expected results:

sakaki@koneko ~ $ firejail --noblacklist=/usr/bin/xinput --x11=xorg --profile=/etc/firejail/firefox.profile bash
Reading profile /etc/firejail/firefox.profile
Reading profile /etc/firejail/firefox.local
Reading profile /etc/firejail/disable-common.inc
Reading profile /etc/firejail/disable-devel.inc
Reading profile /etc/firejail/disable-programs.inc
Reading profile /etc/firejail/whitelist-common.inc
Warning: noroot option is not available
Parent pid 14162, child pid 14163
Blacklist violations are logged to syslog
Using authority file /tmp/.tmpXauth-lEOGMj
authorization id is 1452
Writing authority file /tmp/.tmpXauth-lEOGMj
Child process initialized in 192.68 ms
sakaki@koneko ~ $ xinput list
⎡ Virtual core pointer                    	id=2	[master pointer  (3)]
⎜   ↳ Virtual core XTEST pointer              	id=4	[slave  pointer  (2)]
⎜   ↳ HID 04b4:0033                           	id=8	[slave  pointer  (2)]
⎣ Virtual core keyboard                   	id=3	[master keyboard (2)]
    ↳ Virtual core XTEST keyboard             	id=5	[slave  keyboard (3)]
    ↳ Power Button                            	id=6	[slave  keyboard (3)]
    ↳ Power Button                            	id=7	[slave  keyboard (3)]
    ↳ Logitech USB Keyboard                   	id=9	[slave  keyboard (3)]
    ↳ Logitech USB Keyboard                   	id=10	[slave  keyboard (3)]

Other commands, such as xinput test 9 worked too. So (still in the sandbox, I tried):

sakaki@koneko ~ $ xauth -v list
Using authority file /run/user/1000/gdm/Xauthority
<snip>

Note that /run/user/1000/gdm/Xauthority is not the ~/.Xauthority path that firejail bind mounts its untrusted xauthority into:

firejail/src/firejail/x11.c

Lines 1195 to 1217 in a1530b3

// Ensure there is already a file in the usual location, so that bind-mount below will work.
// todo: fix TOCTOU races, currently managed by imposing /usr/bin/xauth as executable
char *dest;
if (asprintf(&dest, "%s/.Xauthority", cfg.homedir) == -1)
errExit("asprintf");
if (stat(dest, &s) == -1) {
// create an .Xauthority file
touch_file_as_user(dest, getuid(), getgid(), 0600);
}
if (is_link(dest)) {
fprintf(stderr, "Error: .Xauthority is a symbolic link\n");
exit(1);
}
// mount
if (mount(RUN_XAUTHORITY_SEC_FILE, dest, "none", MS_BIND, "mode=0600") == -1) {
fprintf(stderr, "Error: cannot mount the new .Xauthority file\n");
exit(1);
}
// just in case...
if (set_perms(dest, getuid(), getgid(), 0600))
errExit("set_perms");
free(dest);

I am running a GNOME 3 desktop, with gdm as the login manager. The above /run/user/1000/gdm/Xauthority is still present (not blacklisted) in the sandbox environment, and selected by default as the XAUTHORITY:

sakaki@koneko ~ $ # still in the sandbox
sakaki@koneko ~ $ env | grep XAUTHORITY
XAUTHORITY=/run/user/1000/gdm/Xauthority
sakaki@koneko ~ $ ls -l .Xauthority # NB this untrusted auth file is present, but not used
-rw------- 1 sakaki sakaki 50 Nov 17 18:49 .Xauthority
sakaki@koneko ~ $ ls -l /run/user/1000/gdm/Xauthority
-rwx------ 1 sakaki sakaki 98 Nov 17 17:30 /run/user/1000/gdm/Xauthority

Trying to force the issue seemed to work (above sandbox was closed first):

sakaki@koneko ~ $ firejail --noblacklist=/usr/bin/xinput --x11=xorg --env=XAUTHORITY="${HOME}/.Xauthority" --blacklist="${XAUTHORITY}" --profile=/etc/firejail/firefox.profile bash
Reading profile /etc/firejail/firefox.profile
Reading profile /etc/firejail/firefox.local
Reading profile /etc/firejail/disable-common.inc
Reading profile /etc/firejail/disable-devel.inc
Reading profile /etc/firejail/disable-programs.inc
Reading profile /etc/firejail/whitelist-common.inc
Warning: noroot option is not available
Parent pid 14227, child pid 14228
Blacklist violations are logged to syslog
Using authority file /tmp/.tmpXauth-AgCr9y
authorization id is 1455
Writing authority file /tmp/.tmpXauth-AgCr9y
Child process initialized in 153.40 ms
sakaki@koneko ~ $ xinput list
X Input extension not available.

But appeared to be easily overridden in the sandbox (even though /run/user/1000/gdm/Xauthority was inaccessible now), by simply blanking the environment variable:

sakaki@koneko ~ $ # still in the sandbox
sakaki@koneko ~ $ XAUTHORITY="" xinput list
⎡ Virtual core pointer                    	id=2	[master pointer  (3)]
⎜   ↳ Virtual core XTEST pointer              	id=4	[slave  pointer  (2)]
⎜   ↳ HID 04b4:0033                           	id=8	[slave  pointer  (2)]
⎣ Virtual core keyboard                   	id=3	[master keyboard (2)]
    ↳ Virtual core XTEST keyboard             	id=5	[slave  keyboard (3)]
    ↳ Power Button                            	id=6	[slave  keyboard (3)]
    ↳ Power Button                            	id=7	[slave  keyboard (3)]
    ↳ Logitech USB Keyboard                   	id=9	[slave  keyboard (3)]
    ↳ Logitech USB Keyboard                   	id=10	[slave  keyboard (3)]

Anyway, as I said I have a working xephyr setup that I'm writing up now, but thought this might be useful info to pass on, as there have been a few other reports of --x11=xorg not behaving quite as expected (e.g. #57 (comment)).

I am running version 0.9.50 of firejail from the standard Gentoo repos.

@SkewedZeppelin
Copy link
Collaborator

An easier solution* is to simply run GNOME under Wayland. Wayland adds a decent amount of separation, however a lot of the community always says its useless since the apps aren't sandboxed. But Wayland + Firejail makes for an awesome combination.

Be warned though that even under Wayland that legacy X apps will still be able to see the input of other X apps (since they all share a single Xwayland process). Eg. if you're playing a proprietary game its anticheat might key-log what you type into Chromium, but at least it can't capture your screen (I think).

You can see what apps are currently using X by running xlsclients

@sakaki-
Copy link
Author

sakaki- commented Nov 17, 2017

@SpotComms, thanks for the tip. My guide is currently oriented towards to those using GNOME on X11, but I will probably migrate it to cover Wayland at some point in the future.

That being said, the xephyr approach works well enough; the point of filing this issue is really to point out that for GNOME 3 / gdm at least, the user's xauthority file is not in the ~/.Xauthority location that firejail expects (and bind-mounts a freshly created, untrusted .Xauthority over when --x11=xorg is specified), nor is the actual gdm xauthority path (/run/user/<uid>/gdm/Xauthority) blacklisted, so people may get a false sense of security. Perhaps a warning could be printed if using --x11=xorg and the environment $XAUTHORITY is not pointing to the expected path.

@smitsohu smitsohu added the enhancement New feature request label Mar 5, 2018
@smitsohu smitsohu reopened this Oct 8, 2019
@smitsohu
Copy link
Collaborator

smitsohu commented Oct 8, 2019

Hm, turns out the experimental fix b35c000 is broken as well.

I was under the impression I had it working 😕

I'll probably have to revert it. Even though some issues remain, the fix IMHO is a step in the right direction, so not reverting

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
enhancement New feature request
Projects
None yet
Development

No branches or pull requests

3 participants