| View previous topic :: View next topic |
| Author |
Message |
mv
Watchman
Joined: 20 Apr 2005
Posts: 6747
|
 Posted: Tue Apr 13, 2021 4:23 pm Post subject: |
 |
|
| user wrote: | | why not isolate browser process itself, e.g. with sys-apps/bubblewrap ? |
The unix way of privilege separation is a different user. Namespaces is something which might come in addition. Also, it probably won't help with the problem of missing X access (if surprisingly it should help, then the isolation is certainly insufficient.) |
|
| Back to top |
|
 |
mike155
Advocate
Joined: 17 Sep 2010
Posts: 4438
Location: Frankfurt, Germany
|
| Posted: Tue Apr 13, 2021 5:42 pm Post subject: |
|
|
| Quote: | | The unix way of privilege separation is a different user. |
Exactly!
There's another reason, at least for me. I want to make sure that programs I use won't phone home. Therefore I disabled internet access for my standard user. Any program that tries to phone home will fail at the firewall. 
But browsers need access to the internet, of course. Therefore I start my browser from a user whose internet access is not blocked. |
|
| Back to top |
|
|
Zucca
Moderator
Joined: 14 Jun 2007
Posts: 3342
Location: Rasi, Finland
|
| Posted: Tue Apr 13, 2021 7:21 pm Post subject: |
|
|
| mike155 wrote: | | Quote: | | The unix way of privilege separation is a different user. |
Exactly! |
While I'm very much with you in this, there's one problem - *nix systems are multi-user. A "normal user" doesn't necessarily have root access. Think of a situation where you have a remote access to a Linux box that's not yours. What are the options then to run a untrusted program?
_________________
..: Zucca :..
Gentoo IRC channels reside on Libera.Chat.
--
| Quote: | | I am NaN! I am a man! |
|
|
| Back to top |
|
|
mv
Watchman
Joined: 20 Apr 2005
Posts: 6747
|
| Posted: Wed Apr 14, 2021 5:37 am Post subject: |
|
|
| mike155 wrote: | | There's another reason, at least for me. I want to make sure that programs I use won't phone home. Therefore I disabled internet access for my standard user. Any program that tries to phone home will fail at the firewall. :) |
I have the same setup, but for different reasons. (If I won't trust a program, I would not run it under my "trusted" user anyway.)
For me the reason is simply that I do not start a browser or something similar with the "trusted" user by accident.
| Zucca wrote: | | Think of a situation where you have a remote access to a Linux box that's not yours. What are the options then to run a untrusted program? |
It is then the responsibility of the administrator to set up corresponding users and rules. If they don't, they cannot expect that data of their users are not leaked, and the users should not expect such a safety. |
|
| Back to top |
|
|
mv
Watchman
Joined: 20 Apr 2005
Posts: 6747
|
| Posted: Wed Apr 14, 2021 5:45 pm Post subject: |
|
|
After doing some investigation, it seems that Xwayland is intentionally not called with the -auth argument by wlroots.
Unfortunately, the arguments are hardcoded.
I patched wlroots so that it calls | Code: | | Xwayland NULL -rootless -terminate -auth -listen NULL -listen NULL -wm NULL |
but after this modification, I could not start xterm anymore... |
|
| Back to top |
|
|
Anon-E-moose
Watchman
Joined: 23 May 2008
Posts: 6098
Location: Dallas area
|
| Posted: Wed Apr 14, 2021 6:02 pm Post subject: |
|
|
You could always start Xwayland before the wayland compositor (wm) with what flags you wanted, rather than let it be auto started.
But I'm not sure whether -auth works for Xwayland, it may be left over and do nothing or do things you don't expect.
_________________
PRIME x570-pro, 3700x, 6.1 zen kernel
gcc 13, profile 17.0 (custom bare multilib), openrc, wayland |
|
| Back to top |
|
|
Anon-E-moose
Watchman
Joined: 23 May 2008
Posts: 6098
Location: Dallas area
|
| Posted: Wed Apr 14, 2021 6:08 pm Post subject: |
|
|
| mv wrote: | After doing some investigation, it seems that Xwayland is intentionally not called with the -auth argument by wlroots.
Unfortunately, the arguments are hardcoded.
I patched wlroots so that it calls | Code: | | Xwayland NULL -rootless -terminate -auth -listen NULL -listen NULL -wm NULL |
but after this modification, I could not start xterm anymore... |
Possibly because -auth is trying to take -listen as it's arg? 
| Code: | | -auth file select authorization file |
Edit to add: from an X11 session
| Code: | 2073 tty1 \_ /bin/sh /home/don/bin/startx
2091 tty1 \_ xinit /home/don/.xinitrc -- /etc/X11/xinit/xserverrc :1 -auth /tmp/serverauth.qktIGvHI5H
2092 tty7 \_ /usr/bin/X -nolisten tcp :1 -auth /tmp/serverauth.qktIGvHI5H |
ETA2: looking at a few things, not sure if -auth will even work if you use the flag, because Xwayland is set up to use uuid, at least that's my understanding from reading various things.
The documentation for all aspects of wayland, sucks exceedingly, as it's practically non-existent, but in a way it does remind me of X in xfree86 days. [/rant]
_________________
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: Thu Apr 15, 2021 6:56 am Post subject: |
|
|
| Anon-E-moose wrote: | | Possibly because -auth is trying to take -listen as it's arg? :?: |
Yep. After passing a filename as an argument, xterm comes up. Unfortunately, no change, and the passed file is never touched (even if I create it manually, before). It seems that the argument is simply ignored.
| Quote: | | ETA2: looking at a few things, not sure if -auth will even work if you use the flag, because Xwayland is set up to use uuid, at least that's my understanding from reading various things. |
I am afraid that you are right. This policy makes wayland a security risk for my systems. So I will dump wayland for now and stick with X as long as I can. |
|
| Back to top |
|
|
Anon-E-moose
Watchman
Joined: 23 May 2008
Posts: 6098
Location: Dallas area
|
| Posted: Thu Apr 15, 2021 9:13 am Post subject: |
|
|
X will be around for a long time, just like cobol, it just won't get any new development. I expect maintenance releases from now on.
_________________
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: Fri Apr 16, 2021 7:38 am Post subject: |
|
|
Passing "-xauth file" works!
The point is: The caller has to fill the file in advance with X-cookies!
So after the patch I can run X programs as another user with sudox.
Unfortunately, all chrome windows and extensions still die when I run chrome with the unprivileged user, although there is no such problem with the original X. |
|
| Back to top |
|
|
Anon-E-moose
Watchman
Joined: 23 May 2008
Posts: 6098
Location: Dallas area
|
| Posted: Fri Apr 16, 2021 12:07 pm Post subject: |
|
|
| mv wrote: | Passing "-xauth file" works!
The point is: The caller has to fill the file in advance with X-cookies!
So after the patch I can run X programs as another user with sudox.
Unfortunately, all chrome windows and extensions still die when I run chrome with the unprivileged user, although there is no such problem with the original X. |
What are they dying with? Permission problems? or can't find the socket?
_________________
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: Fri Apr 16, 2021 1:29 pm Post subject: |
|
|
| Quote: | | What are they dying with? Permission problems? or can't find the socket? |
Aww, snap!
It is very strange: When I retried, I could not even open xterm, again (with the "main" user).
Then I did the following (which is the same which I already did before my previous post):
- I finished the running X session by switching to a console and running as root /etc/init.d/display-manager stop
- I copied ~/.Xauthority to /path/to/dedicated/file (where my experimental patch in the call of Xwayland had added the argument -xauth /path/to/dedicated/file)
- Started wayland as the "main" user
Suprisingly, this time not only xterm worked but also chrome. I have absolutely no idea what should have been different this time. I also have no idea why Xwayland apparently did not work for the main user in the second attempt (when I attempted to "reuse" the /path/to/dedicated/file without "refreshing" it from another X session). |
|
| Back to top |
|
|
mv
Watchman
Joined: 20 Apr 2005
Posts: 6747
|
| Posted: Fri Apr 16, 2021 3:28 pm Post subject: |
|
|
The following trick worked without any binary patching: I created an executable script in my main user's $PATH named "xwayland-auth".
| Code: | #!/bin/sh
set -u
Echo() {
printf '%s\n' "$*"
}
Die() {
Echo "$*" >&2
exit ${1:-1}
}
case ${1:--} in
:[0-9]|:[0-9][0-9])
display=$1
shift;;
*)
Die "Bad display ${1:--}";;
esac
authfile=$HOME/.Xauthority
mcookie=`mcookie` || Die 'mcookie failed'
Echo "add $display . $mcookie" | xauth -q -f "$authfile" \
|| Die "xauth -f $xauthfile failed"
exec Xwayland "$display" -auth "$authfile" "$@" |
and then I "cheat" wlroots into using my script instead of Xwayland by setting WLR_XWAYLAND correspondingly:
| Code: | #!/bin/sh
set -u
set -e
export GDK_BACKEND=x11 # wayland does not work yet with emacs
export QT_QPA_PLATFORM=wayland-egl \
SDL_VIDEODRIVER=wayland \
XDG_SESSION_TYPE=wayland \
MOZ_ENABLE_WAYLAND=1 \
WLR_DRM_NO_MODIFIERS=1 \
CLUTTER_BACKEND=wayland \
ELM_DISPLAY=wl \
ELM_ACCEL=opengl \
ECORE_EVAS_ENGINE=wayland_egl # wayland_shm
export WLR_XWAYLAND=`command -v xwayland-auth`
# /usr/bin/env hooks in all of the environmental variables set using startw(1).
exec /usr/bin/wayfire >"$HOME"/.local/share/wayfire.log 2>&1 |
Edit: Minor script improvements
Last edited by mv on Fri Apr 16, 2021 3:59 pm; edited 2 times in total |
|
| Back to top |
|
|
Anon-E-moose
Watchman
Joined: 23 May 2008
Posts: 6098
Location: Dallas area
|
| Posted: Fri Apr 16, 2021 3:37 pm Post subject: |
|
|
Looks good, long as it works. 
_________________
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: Fri Apr 16, 2021 5:49 pm Post subject: |
|
|
Aw snap:
Again, all chrome extensions crash (chrome just reports that they crashed), and all chrome windows show "Aw snap" (for the unprivileged user).
It is exactly the setup I described above which worked previously: After a reboot, it no longer works, and all attempts to get it to work (running "standard" X in between, etc.) failed...
(Other X applications like emacs run without problems with the unprivileged user). |
|
| Back to top |
|
|
Anon-E-moose
Watchman
Joined: 23 May 2008
Posts: 6098
Location: Dallas area
|
| Posted: Fri Apr 16, 2021 7:08 pm Post subject: |
|
|
I'm not sure why it worked in the first place, but command -v xwayland-auth, just might want a path in front of xway...
_________________
PRIME x570-pro, 3700x, 6.1 zen kernel
gcc 13, profile 17.0 (custom bare multilib), openrc, wayland |
|
| Back to top |
|
|
Anon-E-moose
Watchman
Joined: 23 May 2008
Posts: 6098
Location: Dallas area
|
| Posted: Fri Apr 16, 2021 8:42 pm Post subject: |
|
|
You were close with your script.
Try this (might work, emphasis on might )
| Code: | $ cat bin/Xwayland.sh
#!/bin/sh
authfile=$HOME/.Xauthority
xauth -q -f "$authfile" add $1 . `mcookie`
exec Xwayland "$@" -auth "$authfile"
|
set WLR_XWAYLAND to your shell script (make sure it's executable)
export WLR_XWAYLAND="/<path to script>/Xwayland.sh"
Note, wlroots always passes display and other args to Xwayland, leave the args alone, just add your commands at the end. (see above)
_________________
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: Sat Apr 17, 2021 5:29 am Post subject: |
|
|
| Anon-E-moose wrote: | | I'm not sure why it worked in the first place, but command -v xwayland-auth, just might want a path in front of xway... |
No, the purpose of command -v is to add the path. Might not be necessary, but I did not try without a path.
| Quote: | | Note, wlroots always passes display and other args to Xwayland, leave the args alone, just add your commands at the end. (see above) |
No, I had tried that first, and when adding the -auth ... at the end, xterm did not come up, again. It worked, however, if the -auth .. is added as the first option after the display.
I am sure that my scripts work perfectly as they should: Other things like emacs can be used with the untrusted user. (And once it was even possible to use chrome with the script).
However, with chrome I still had no success so far. I conjecture that this is somehow related with the fact that X is started over sddm which does some session registering (though it is configured for systemd, and I have not booted with systemd). |
|
| Back to top |
|
|
mv
Watchman
Joined: 20 Apr 2005
Posts: 6747
|
| Posted: Sat Apr 17, 2021 6:55 am Post subject: |
|
|
I created now an /usr/share/wayland-sessions/wayfire-mv,desktop which calls my script instead of the wayfire binary and extended my script to source the bashrc which sets variables like XDG_RUNTIME_DIR.
After this, surprisingly, I can start a wayfire session (once more: sddm is compiled with systemd support, but the machine was booted with openrc). Moreover, in this wayfire session, I can change to an untrusted user with sudox who then can run chrome without any problems!
So the problem currently seems to be solved, although I have no idea what is the magic done by sddm which make chrome work. Moreover, I am afraid that this one-time success might be just some accident like previously. |
|
| Back to top |
|
|
mv
Watchman
Joined: 20 Apr 2005
Posts: 6747
|
| Posted: Sat Apr 17, 2021 7:10 am Post subject: |
|
|
| It works even after a reboot. Note also that I gave no access to the wayland socket ($XDG_RUNTIME_DIR) for the untrusted user, that is, passing the X cookies with sudox was all which was needed for chrome. (Of course, chrome runs in X mode, not in native wayland mode, here: As mentioned earlier, chrome crashed immediately at the start attempt - even for the main user - when I had added -enable-features=UseOzonePlatform -ozone-platform=wayland) |
|
| Back to top |
|
|
mv
Watchman
Joined: 20 Apr 2005
Posts: 6747
|
| Posted: Sat Apr 17, 2021 7:45 am Post subject: |
|
|
Now I investigated the native wayland mode of chrome:
It works for my main user after I added it to the graphics group and rebooted (not sure why the latter was necessary): The problem was that it had no access to /dev/dri/card0 which has the permissions | Code: | /dev/dri:
crw-rw---- 1 root graphics card0 |
It works also for my "untrusted" user if this user is a member of the graphics group, if I make $XDG_RUNTIME_DIR accessible for its group (of the untrusted user), if I make $XDG_RUNTIME_DIR/wayland-1 owned by the same group, if I make this socket group writable (by default, it has only permissions srwxr-xr-x), and if I export WAYLAND_DISPLAY=$XDG_RUNTIME_DIR_OF_TRUSTED_USER/wayland-1 for the untrusted user.
Not sure yet what is a good way to automate all this. Perhaps using acls (XDG_RUNTIME_DIR is on a tmpdir which has acl enabled) instead of group permissions is a good idea. I still have to find out how to set acls in this case. |
|
| Back to top |
|
|
Anon-E-moose
Watchman
Joined: 23 May 2008
Posts: 6098
Location: Dallas area
|
| Posted: Sat Apr 17, 2021 9:23 am Post subject: |
|
|
I run seatd which is in the video group and handles talking to /dev/dri.
As far as I know the only parm that's position dependent is the first one (display)
If you're going to try and override the wlroots parms, then get rid of the 1st one, the display, as you are supplying your own, at least from the original script.
When you put -auth <authfile> as last parm, did it show up as a parm under "ps axf -o pid,tty,args" for Xwayland.
I know I tried with a test parm "retro" and it didn't do anything (to be expected, it's a wayland screen I see, not an X one. But the parm showed up which means it's being passed from my script.
Wayland mode for things like chrome can be screwy. It uses gtk. For FF if you set this export GDK_BACKEND=wayland, then it'll likely crash.
Having said that gtk+3 is wayland aware. But browsers are funny critters, and who knows how they're written internally, especially with plugins, etc.
Socket permissions are almost always set as 777, no matter the app.
| Code: | $ dir /tmp/.runtime-don/
total 0
drwx------ 5 don don 180 Apr 17 03:49 .
drwxrwxrwt 10 root root 260 Apr 17 03:49 ..
drwx------ 3 don don 60 Mar 20 16:04 dbus-1
drwxr-xr-x 2 don don 60 Apr 13 18:35 deadbeef
drwx------ 2 don don 40 Apr 2 08:37 doc
srwxrwxrwx 1 don don 0 Apr 14 18:26 wayland-0
-rw-rw---- 1 don don 0 Apr 14 18:26 wayland-0.lock
srwxrwxrwx 1 don don 0 Apr 17 03:49 wayland-1
-rw-rw---- 1 don don 0 Apr 14 07:17 wayland-1.lock |
I created the runtime dir, but the permissions for socket, lock, and dir's are done by wayland/some app.
I have seen recommendations for acl permission for second/other users, rather than change runtime dir permissions, to me six of one, half-dozen of the other.
For acl /bin/getfacl /bin/setfacl
_________________
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: Sat Apr 17, 2021 4:14 pm Post subject: |
|
|
Good news:
I released a new version of sudox which does all stuff required for Xwayland and native wayland (the new release is in the mv overlay already).
In particular, it contains the two scripts I posted above and a .desktop file for a corresponding wayland-auth session.
Moreover, sudox now passes/modifies the required environment variables and grants permissions using setfattr.
| Anon-E-moose wrote: | | I run seatd which is in the video group and handles talking to /dev/dri. |
I also do, but apparently chrome wants in wayland mode direct access to that device.
| Quote: | | As far as I know the only parm that's position dependent is the first one (display) |
I had expected this as well, but it turned out that it is not the case. htop showed me that the "correct" parameters are passed, but the -auth argument was ignored. Putting it on the second position, it worked.
| Quote: | | If you're going to try and override the wlroots parms, then get rid of the 1st one, the display, as you are supplying your own, at least from the original script. |
I do; maybe you missed the "shift" inside of the case?
| Quote: | | Socket permissions are almost always set as 777, no matter the app. |
The permissions are funny here: They are sometimes 775. sometimes 750, and sometimes 777, depending on whether I call it directly or through sdm and whether I started X and/or wayland before. I forgot the details, but with sddm I never had 777. Similarly for the lock file (not sure what it is good for, but I suppose the untrusted user should better be able to take a lock as well to avoid races).
| Quote: | | I have seen recommendations for acl permission for second/other users, rather than change runtime dir permissions, to me six of one, half-dozen of the other. |
I went now for the acl approach: Otherwise, there arise difficulties if there are several "untrusted" users which do not belong to the same group. Also a general automated script like "sudox" is hard to write unless you explicitly pass the required group which somehow undermines the automaticity wanted from such a script.
| Quote: | | For acl /bin/getfacl /bin/setfacl |
So far, I managed to avoid virtual/acl, since all real-life users on my system are completely trusted. But it seems that now I have to byte the bullet only for this single script... |
|
| Back to top |
|
|
Zucca
Moderator
Joined: 14 Jun 2007
Posts: 3342
Location: Rasi, Finland
|
| Posted: Tue Apr 27, 2021 6:32 am Post subject: |
|
|
mv: Care to put information of your project on the wiki? ;)
Maybe on the Wayland article?
_________________
..: Zucca :..
Gentoo IRC channels reside on Libera.Chat.
--
| Quote: | | I am NaN! I am a man! |
|
|
| Back to top |
|
|
mv
Watchman
Joined: 20 Apr 2005
Posts: 6747
|
| Posted: Tue Apr 27, 2021 9:59 am Post subject: |
|
|
| Zucca wrote: | mv: Care to put information of your project on the wiki? ;)
Maybe on the Wayland article? |
Done |
|
| Back to top |
|
|
|
|
You cannot post new topics in this forum
You cannot reply to topics in this forum
You cannot edit your posts in this forum
You cannot delete your posts in this forum
You cannot vote in polls in this forum
|
|
Desktop Environments
