View previous topic :: View next topic |
Author |
Message |
mv Watchman
Joined: 20 Apr 2005 Posts: 6747
|
Posted: Sat Apr 10, 2021 7:48 pm Post subject: wayland: Run a browser with reduced privileges [Solved] |
|
|
In X, it was possible to run a browser with a low-privileged user: All you needed was an appropriate .Xauthority file in the home directory of the low-privileged user (and some variables exported).
How is the analogous thing done in wayland, in particular with seatd?
I assume that the question reads more precisely: Is it possible to register a second (low-privileged) user with seatd somehow? (Or can a window in a running compositor with the low privileged user also be opened in another way?)
Summary of the discussion: All steps necessary to do this are now contained in sudox (ebuild available for gentoo through the mv overlay).
Last edited by mv on Sat Apr 17, 2021 4:18 pm; edited 1 time in total |
|
Back to top |
|
|
Anon-E-moose Watchman
Joined: 23 May 2008 Posts: 6095 Location: Dallas area
|
Posted: Sat Apr 10, 2021 9:17 pm Post subject: |
|
|
I assume you mean the fact that X ran as root and thus the need for low privileged users.
Code: | root 3316 ? /usr/bin/seatd -g video
...
don 18546 tty1 -bash
don 17239 tty1 \_ /bin/bash /home/don/bin/startw
don 17240 tty1 \_ dbus-run-session -- /usr/bin/wayfire
don 17241 tty1 \_ dbus-daemon --nofork --print-address 4 --session
don 17242 tty1 \_ /usr/bin/wayfire
don 17267 tty1 Xwayland :0 -rootless -terminate -core -listenfd 20 -listenfd 21 -wm 24
don 17273 tty1 wf-background
don 17275 tty1 dunst
don 17277 tty1 kanshi
don 17279 tty1 waybar
don 17359 tty1 deadbeef
don 14957 tty1 /opt/palemoon/palemoon -P default
don 30942 tty1 /usr/bin/firefox -no-remote -P ds |
Everything runs as my user, the only group I'm in is input as starting from the command line you need to see kbd/mouse.
I'm not sure if this is exactly what you're asking. _________________ PRIME x570-pro, 3700x, 6.1 zen kernel
gcc 13, profile 17.0 (custom bare multilib), openrc, wayland |
|
Back to top |
|
|
Hu Moderator
Joined: 06 Mar 2007 Posts: 21431
|
Posted: Sat Apr 10, 2021 10:21 pm Post subject: |
|
|
No, I think mv is asking about using a separate uid just for the browser, so that standard Linux permissions can prevent the browser from reading the regular home directory, signaling other processes, etc.
I am not aware of a way to do this in Wayland, but I have not looked for such a thing. I might start with Firejail instead, which runs the browser as the same uid, but with a severely restricted view of the filesystem and with system call filters. I don't know if this will work any better, but it should bypass the immediate apparent problem that seatd refuses to allow the browser in because of a uid mismatch. |
|
Back to top |
|
|
Anon-E-moose Watchman
Joined: 23 May 2008 Posts: 6095 Location: Dallas area
|
Posted: Sat Apr 10, 2021 11:42 pm Post subject: |
|
|
Not sure about the uid browser thing, not sure that seatd even cares.
But the browser would probably need access to the run socket dir, it's usually 700 permissions.
Edit to add: running sudo -u on the low priority user browser might work, you'd have to pass some env vars. _________________ PRIME x570-pro, 3700x, 6.1 zen kernel
gcc 13, profile 17.0 (custom bare multilib), openrc, wayland |
|
Back to top |
|
|
mike155 Advocate
Joined: 17 Sep 2010 Posts: 4438 Location: Frankfurt, Germany
|
Posted: Sun Apr 11, 2021 12:05 am Post subject: |
|
|
There's a tool called 'ego': https://github.com/intgr/ego
Quote: | Ego is a tool to run Linux desktop applications under a different local user. Currently integrates with Wayland, Xorg, PulseAudio and xdg-desktop-portal. You may think of it as xhost for Wayland and PulseAudio. This is done using filesystem ACLs and xhost command. |
EDIT: I just installed ego and gave it a try. It seems to work! The command below changes the user id using sudo and starts Firefox in Wayland mode.
Code: | /usr/local/bin/ego --sudo -u guestuser MOZ_ENABLE_WAYLAND=1 firefox |
Ego uses ACLs to make the Wayland socket accessible to the guest user. Ego doesn't revoke the ACLs when the guest process finishes (see: issue 55). I can live with that, but it might be a problem in some cases.
Last edited by mike155 on Sun Apr 11, 2021 1:57 pm; edited 1 time in total |
|
Back to top |
|
|
mv Watchman
Joined: 20 Apr 2005 Posts: 6747
|
Posted: Sun Apr 11, 2021 9:33 am Post subject: |
|
|
Hu wrote: | No, I think mv is asking about using a separate uid just for the browser, so that standard Linux permissions can prevent the browser from reading the regular home directory, signaling other processes, etc. |
Yes, exactly. I have a separate browser-user with less privileges than my normal user. Of course, under X I have to grant this user full access to my X session. There is a "sux" script which does this, and I have written the more convient "sudox" for it. Essentially, this just copies the X cookies to the unprivileged user.
Anon-E-moose wrote: | But the browser would probably need access to the run socket dir, it's usually 700 permissions |
Where is this file? Does it reside in /tmp?
I am not sure whether it would be enough: google-chrome-stable (if run after sudo-ing to the unprivileged user) just reports "unspecified protocol" - it seems that it has no idea how to access the running wayland session (although I copied all *WAY* environment variables from the privileged to the unprivileged user.) firefox just crashes.
This sounds good, but it seems to use systemd (which I am not using) to do its magic. So far, I was not able to understand from the source code what the essential step is which needs to be done for wayland. |
|
Back to top |
|
|
Anon-E-moose Watchman
Joined: 23 May 2008 Posts: 6095 Location: Dallas area
|
Posted: Sun Apr 11, 2021 9:59 am Post subject: |
|
|
Ego seems interesting
Code: | Requirements:
Rust & cargo
libacl.so library (Debian/Ubuntu: libacl1-dev; Fedora: libacl-devel; Arch: acl)
Recommended: (Not needed when using --sudo mode, but some desktop functionality may not work).
machinectl command (Debian/Ubuntu/Fedora: systemd-container; Arch: systemd)
xdg-desktop-portal-gtk (Debian/Ubuntu/Fedora/Arch: xdg-desktop-portal-gtk) |
It looks for systemd (at least from my cursory look) but it looks like it's recommended not required.
...
The runtime directory is wherever you put it, systemd (and I assume elogind) would put it in /run for you
If you create it yourself, like I've done, you can put it in /tmp.
Within that runtime dir (for me running dbus) it creates a dbus-1 dir with 700 permissions, so that would also need to be changed.
But even with that, I'm not sure ff as you envision it would work. Or as mentioned above it might work with a sudo user change,
but to know for sure would require testing it.
Code: | $ dir /tmp/.runtime-don/
total 0
drwx------ 5 don don 140 Apr 11 04:37 .
drwxrwxrwt 10 root root 260 Apr 11 04:38 ..
drwx------ 3 don don 60 Mar 20 16:04 dbus-1
drwxr-xr-x 2 don don 40 Mar 20 16:58 deadbeef
d????????? ? ? ? ? ? doc
srwxrwxrwx 1 don don 0 Apr 11 04:37 wayland-1
-rw-rw---- 1 don don 0 Apr 2 15:02 wayland-1.lock |
As you can see the main dir .runtine-don and the dbus-1 dir are 700, the socket itself has all permissions, the lock file would need other added at least for read, (deadbeef is my music player), and the "doc dir" I'm not sure about it's something that gets created and ls and other tools don't really understand it, thus the ???
What I would try is start wayland, bring up a terminal, and from that do a sudo -u <whatever ff user> firefox and see what happens.
I truly don't know what will happen, that's why I'm a little vague. _________________ PRIME x570-pro, 3700x, 6.1 zen kernel
gcc 13, profile 17.0 (custom bare multilib), openrc, wayland |
|
Back to top |
|
|
mike155 Advocate
Joined: 17 Sep 2010 Posts: 4438 Location: Frankfurt, Germany
|
Posted: Sun Apr 11, 2021 12:02 pm Post subject: |
|
|
mv wrote: | So far, I was not able to understand from the source code what the essential step is which needs to be done for wayland. |
Ego performs the steps below:
- It gets the path to the Wayland socket
- It makes the socket accessible for the guest user using ACLs
- It switches to the guest user using either machinectl or sudo
- It sets the WAYLAND_DISPLAY environment variable to point to the socket
You can try it manually. It works!
Code: | chmod oug+rwx /tmp/temp-myuser/runtime/wayland-0 # dangerous, but adequate for a demo
chmod oug+rx /tmp/temp-myuser/runtime/
chmod oug+rx /tmp/temp-myuser
su - guestuser
export WAYLAND_DISPLAY="/tmp/temp-myuser/runtime/wayland-0"
MOZ_ENABLE_WAYLAND=1 firefox |
|
|
Back to top |
|
|
Zucca Moderator
Joined: 14 Jun 2007 Posts: 3309 Location: Rasi, Finland
|
Posted: Sun Apr 11, 2021 12:52 pm Post subject: |
|
|
Before I start writing... does this ego have a working ebuild somewhere? _________________ ..: Zucca :..
Gentoo IRC channels reside on Libera.Chat.
--
Quote: | I am NaN! I am a man! |
|
|
Back to top |
|
|
mike155 Advocate
Joined: 17 Sep 2010 Posts: 4438 Location: Frankfurt, Germany
|
Posted: Sun Apr 11, 2021 1:02 pm Post subject: |
|
|
I installed it manually:
Code: | cargo install ego
sudo cp ~/.cargo/bin/ego /usr/local/bin/ |
Don't forget to add the entry in /etc/sudoers, if you want to use 'ego --sudo' to switch to the guest user. |
|
Back to top |
|
|
mv Watchman
Joined: 20 Apr 2005 Posts: 6747
|
Posted: Sun Apr 11, 2021 1:33 pm Post subject: |
|
|
mike155 wrote: | - It gets the path to the Wayland socket
- It makes the socket accessible for the guest user using ACLs
- It switches to the guest user using either machinectl or sudo
- It sets the WAYLAND_DISPLAY environment variable to point to the socket
You can try it manually. It works!
Code: | chmod oug+rwx /tmp/temp-myuser/runtime/wayland-0 # dangerous, but adequate for a demo
chmod oug+rx /tmp/temp-myuser/runtime/
chmod oug+rx /tmp/temp-myuser
su - guestuser
export WAYLAND_DISPLAY="/tmp/temp-myuser/runtime/wayland-0"
MOZ_ENABLE_WAYLAND=1 firefox |
|
Finally, I understood where the socket is: In XDG_RUNTIME_DIR. (In my case, WAYLAND_DISPLAY was just wayland-1, not an absolute path).
For chrome, it did not work for me: It complained about invalid X cookies, although I exported the current X cookies (from my running xterm) using sudox. I assume that it somehow opens a new X-Server with different cookies. |
|
Back to top |
|
|
mike155 Advocate
Joined: 17 Sep 2010 Posts: 4438 Location: Frankfurt, Germany
|
Posted: Sun Apr 11, 2021 1:56 pm Post subject: |
|
|
mv wrote: | For chrome, it did not work for me: It complained about invalid X cookies, although I exported the current X cookies (from my running xterm) using sudox. I assume that it somehow opens a new X-Server with different cookies. |
It works for me:
Code: | /usr/local/bin/ego --sudo -u guestuser google-chrome-stable -enable-features=UseOzonePlatform -ozone-platform=wayland |
But it was necessary to add guestuser to the video group. |
|
Back to top |
|
|
Anon-E-moose Watchman
Joined: 23 May 2008 Posts: 6095 Location: Dallas area
|
Posted: Sun Apr 11, 2021 2:32 pm Post subject: |
|
|
mv wrote: | For chrome, it did not work for me: It complained about invalid X cookies, |
The guest user probably wants a copy of what's in your .xauth file _________________ PRIME x570-pro, 3700x, 6.1 zen kernel
gcc 13, profile 17.0 (custom bare multilib), openrc, wayland |
|
Back to top |
|
|
mv Watchman
Joined: 20 Apr 2005 Posts: 6747
|
Posted: Sun Apr 11, 2021 2:42 pm Post subject: |
|
|
mike155 wrote: | Code: | /usr/local/bin/ego --sudo -u guestuser google-chrome-stable -enable-features=UseOzonePlatform -ozone-platform=wayland |
|
I did not know these options. When I use them, I get the error message "cannot connect to the wayland server" (even for the "main" user). Probably for some reason, chrome runs in X mode only for me.
Edit: Both users are in the video group
Anon-E-moose wrote: | The guest user probably wants a copy of what's in your .xauth file |
But this happened even after I used sudox to transfer the cookies (that is, essentially copying the .Xauthority file). It seems like a new session+cookies are created from running the binary until chrome is started!? |
|
Back to top |
|
|
Anon-E-moose Watchman
Joined: 23 May 2008 Posts: 6095 Location: Dallas area
|
Posted: Sun Apr 11, 2021 3:18 pm Post subject: |
|
|
mv wrote: | But this happened even after I used sudox to transfer the cookies (that is, essentially copying the .Xauthority file). It seems like a new session+cookies are created from running the binary until chrome is started!? |
Never used sudox so don't know exactly what it does.
Does it say anything about the display :0, :1, etc when you try and run chrome?
Because what you want is chrome to start up but use your X display, which will involve the xauth file. Just not sure what to modify or add.
Edit to add: maybe something like this https://serverfault.com/questions/51005/how-to-use-xauth-to-run-graphical-application-via-other-user-on-linux
You might start with a >/tmp/chrome.log 2>&1 after the command so that you're sure to capture all it complains about. _________________ PRIME x570-pro, 3700x, 6.1 zen kernel
gcc 13, profile 17.0 (custom bare multilib), openrc, wayland |
|
Back to top |
|
|
mv Watchman
Joined: 20 Apr 2005 Posts: 6747
|
Posted: Sun Apr 11, 2021 3:53 pm Post subject: |
|
|
Anon-E-moose wrote: | Never used sudox so don't know exactly what it does. |
It is a wrapper for sudo which calls for the remote user Code: | echo $DATA | xauth nmerge - | with, roughly speaking, $DATA being the data obtained from of the calling user (I am omitting a lot of technical details, of course). Moreover, it transfers some variables like DISPLAY to the remote user. For normal X, it works perfectly, even across ssh -Y. So everything concerning permissions should be set up this way. |
|
Back to top |
|
|
mike155 Advocate
Joined: 17 Sep 2010 Posts: 4438 Location: Frankfurt, Germany
|
|
Back to top |
|
|
mv Watchman
Joined: 20 Apr 2005 Posts: 6747
|
Posted: Sun Apr 11, 2021 4:27 pm Post subject: |
|
|
mike155 wrote: | So it's probably something like Jens Getreu's sudox? |
Yes, except that it is much more luxury in many ways (it calls sudo only once, to start with).
Quote: | We could try to add Wayland support to your or to Jens Getreu's script |
This was my plan. But currently, I am still not even able to do it manually so that chrome works. |
|
Back to top |
|
|
Anon-E-moose Watchman
Joined: 23 May 2008 Posts: 6095 Location: Dallas area
|
Posted: Sun Apr 11, 2021 4:50 pm Post subject: |
|
|
Are you trying to start chrome within a running wayland session? (what it sounds like to me)
If so, when you try and start chrome exactly what does it do?
Does it immediately give the message about X cookies? Are there any other messages?
Apart from the above
Even though a xserver is being started, it's a little different than a normal one started by a user.
This is what I see for the xwayland session for me
Code: | Xwayland :0 -rootless -terminate -core -listenfd 20 -listenfd 21 -wm 24 |
I'm not even sure how to modify the parms passed to xwayland or if it can even be modified. _________________ PRIME x570-pro, 3700x, 6.1 zen kernel
gcc 13, profile 17.0 (custom bare multilib), openrc, wayland |
|
Back to top |
|
|
mv Watchman
Joined: 20 Apr 2005 Posts: 6747
|
Posted: Sun Apr 11, 2021 5:22 pm Post subject: |
|
|
Anon-E-moose wrote: | Are you trying to start chrome within a running wayland session? (what it sounds like to me) |
Yes.
Quote: | If so, when you try and start chrome exactly what does it do? |
When I start it with the original user, the window opens. I suppose in X mode.
Quote: | Does it immediately give the message about X cookies? Are there any other messages? |
Yes. When I start it with the remote user, It gives immediately the message about X cookies and then exits.
When I use the wayland arguments I learnt above, it also gives some error messages which I just forgot then downloads something from google and dies with "Illegal instruction" (no matter whether I run it under the original or the remote user). |
|
Back to top |
|
|
mike155 Advocate
Joined: 17 Sep 2010 Posts: 4438 Location: Frankfurt, Germany
|
Posted: Sun Apr 11, 2021 5:34 pm Post subject: |
|
|
mv wrote: | it calls sudo only once, to start with |
That's the first thing I fixed in Jens Getreu's script when I installed it on my machine
Quote: | I suppose in X mode. |
That's why I start xeyes in my Wayland start script. Xeyes sits in the upper right corner (like 30 years ago) and tells me immediately whether a program runs in X or in Wayland mode. |
|
Back to top |
|
|
Anon-E-moose Watchman
Joined: 23 May 2008 Posts: 6095 Location: Dallas area
|
Posted: Sun Apr 11, 2021 5:36 pm Post subject: |
|
|
I ran across an wiki (arch) https://wiki.archlinux.org/index.php/Running_GUI_applications_as_root
The're talking about allowing root access to the current X (wayland) session and they use xhost to add root to your auth file
---
A more versatile —though much less secure— workaround is to use xhost to temporarily allow the root user to access the local user's X session[5]. To do so, execute the following command as the current (unprivileged) user:
Code: | $ xhost si:localuser:root |
To remove this access after the application has been closed:
Code: | $ xhost -si:localuser:root |
---
instead of root, try adding your guest user name and see what happens. _________________ PRIME x570-pro, 3700x, 6.1 zen kernel
gcc 13, profile 17.0 (custom bare multilib), openrc, wayland |
|
Back to top |
|
|
mv Watchman
Joined: 20 Apr 2005 Posts: 6747
|
Posted: Mon Apr 12, 2021 6:33 am Post subject: |
|
|
Mike155 wrote: | That's the first thing I fixed in Jens Getreu's script when I installed it on my machine |
It is not only about that. It is also about returning a shell by default (hence fd0 and fd1 cannot be used to transfer data, and different mechanisms to transfer data securely have to be used), handling screen and tmux sessions (e.g. opening a new tty if necessary), etc.
Especially the secure transfer made the script rather complex. Best you read the details here.
Anon-E-moose wrote: | A more versatile —though much less secure— workaround |
As they write, it is much less secure. However, maybe you are right that I should try whether it is possible at all. I will report back when I have more time to experiment. |
|
Back to top |
|
|
mv Watchman
Joined: 20 Apr 2005 Posts: 6747
|
Posted: Mon Apr 12, 2021 10:46 am Post subject: |
|
|
I tried, here are the results:
- The X problems are not chrome specific: The same happens with e.g. xeyes or emacs. Although
shows identical entries for both users, the "remote" user gets errors about invalid MIT cookies. With Code: | xhost xi:localuser:name_of_remote_user | things work, but for security reasons this is worse than current X - I better stick with X for the moment if I find no other workaround chrome does not work even after the xhost command: The window opens, but all tabs and all extensions crash (Aww snap). I assume that this is related with chrome sandboxing somehow. |
|
Back to top |
|
|
user Apprentice
Joined: 08 Feb 2004 Posts: 194
|
Posted: Tue Apr 13, 2021 11:48 am Post subject: |
|
|
Hi,
why not isolate browser process itself, e.g. with sys-apps/bubblewrap ? |
|
Back to top |
|
|
|