wlr-protocols
wlr-protocols copied to clipboard
swaywm
[RFC] Add wlr-exec-secure-unstable-v1.xml
My intention is to pair this with two more standards:
- A standard file format for
/etcwhich specifies the permissions a client is authorized for, to be installed with the package for client software - Another protocol which lets you create new wayland sockets authorized to use a subset of your permissions. The purpose of this would be for e.g. flatpak to be authorized to do whatever it wants and add its own permissions on top of that.
This proposal is similar to DBus socket activation.
It has similar issues. For instance, when launching a process from the command-line, the process will be forked in the background by the compositor. This is annoying.
I don't think we can get away from making the compositor execute it. However, if the command line process transfers its stdin/stdout/stderr and environment, then waits for exit and exits with the same status code, the user will be none the wiser.
The re-execution also leads to issues with user session management, be it via systemd user units or e.g.gnome-session. The client using this protocol would need to supervise it's own (compositor spawned) process and can't just rely on e.g. systemd's 'simple' service type for being respawned.
I think that falls under the same model as before. The systemd-spawned process can wait on the compositor spawned process and exit with the same exit code when it does. Then systemd will spawn another and so on.
@Ongy What was the issue with reading the executable name from the PID again? I can't remember why it's racy. (It's still only available on Linux and OpenBSD, not FreeBSD)
That's why I said "can't just rely on 'simple' service" and this is still true. The process needs to do a lot more tracking that is handled by the supervisor otherwise. This means the processes that could just use that model would need to change their behaviour a since it needs access to a privileged protocol. I don't have a better solution to the problem though.
...that said an apparmor module for wayland protocol mediation (similar to dbus mediation) would solve this in linux but it's not cross plattform. While searching for prior art I came across: http://www.mupuf.org/blog/2014/02/19/wayland-compositors-why-and-how-to-handle/ based on this XDC talk https://www.x.org/wiki/Events/XDC2014/XDC2014DodierPeresSecurity/xorg-talk.pdf .
Should we have a separate bug to handle privileged clients (since this protocol is (while possibly part of the solution) about something else)?
I still don't see this as overlapping with a supervisor. The initial process just becomes a dumb proxy of the new process. Any supervisor can just monitor the initial process normally.
...that said an apparmor module for wayland protocol mediation
I don't really want to get AppArmor involved here. I don't think it's necessary and most Linux desktops aren't using it. I want to try to get security into this with a model which will work for most users, and most users aren't going to set up AppArmor.
Should we have a separate bug to handle privileged clients (since this protocol is (while possibly part of the solution) about something else)?
What are you thinking?
I haven't really followed the security considerations for sway so far too much but while reading the discussion the question i mainly had was why clients (like a screenshot or video capture program or clipboard manager) have to work when not invoked by the compositor? Why can't we simply tell users that when they want to execute something that they trust enough to give those permission they have to execute it via the compositor?
That's not a point against this protocol though, its role would be to allow application launcher clients or some cross-compositor wl-exec (instead of only sways exec)
I haven't really followed the security considerations for sway so far too much but while reading the discussion the question i mainly had was why clients (like a screenshot or video capture program or clipboard manager) have to work when not invoked by the compositor? Why can't we simply tell users that when they want to execute something that they trust enough to give those permission they have to execute it via the compositor?
We can. This is just a convenience, and something useful for clients like application launchers which run with lower permissions than the clients they launch.
why clients (like a screenshot or video capture program or clipboard manager) have to work when not invoked by the compositor?
One of the cases where it would not be straightforward to get started from the compositor is anything automated - running an application test suite, remotely requesting a VNC server, etc.
One of the cases where it would not be straightforward to get started from the compositor is anything automated - running an application test suite, remotely requesting a VNC server, etc.
But in those cases, this protocol can be used, right?
I was worried that the spawned program would have to find a new way to share the data from the new interface back to the requester, but this seems to be taken care of in the fd request. So yeah, seems possible.
How does a protocol know that it needs to use this protocol to get elevated permissions?
- The process gets exec'ed
- It uses this protocol to be exec'ed by the compositor
goto 1
Relying on WAYLAND_SOCKET would be very fragile.
Maybe we should add an event to this protocol which indicates if your process was already spawned securely.
I wonder if this can work with Flatpak and/or D-Bus activation. Not that I use these myself.
Oh, by the way, just thought of something: instead of making the compositor a process manager, we could just use a FD which is closed when the spawned client exits. So the "spawner" client code becomes:
int fds[2];
pipe(fds);
// Ask the compositor to spawn ourselves, with dup'ed
// stdin/stdout/sterr, and to close fds[1] on exit
close(fds[1]);
struct pollfd pfd = {
.fd = fds[0],
.events = POLLIN,
};
poll(&pfd, 1, -1);
And the compositor could just do this:
int exit_fd; // FD sent by client
if (fork() == 0) {
exec("/path/to/client");
}
close(exit_fd);
More complicated things to get back the exit code are possible too.
Thought about this a little bit more, and it doesn't seem like this is going to cut it. Replicating a process' environment is not easy: for instance we'd need to forward signals so that typing Ctrl+Z would make the process spawned by the compositor stop. Additionally, the process spawned by the compositor wouldn't inherit the whole environment: there are more portable things like umask, and system-specific things like Linux containers and BSD jails.
Just to clarify a little bit more: this protocol provides a very convenient way to escape process limits, chroots, containers and jails.
@emersion Why would your idea provide a convenient way to escape chroots/containers? If I can connect to the sway socket I can always spawn processes with the privileges of sway, why would the above make things worse, what am I missing?
First of all, this is just brainstorming, maybe someone gets inspired, also I dont know all the implementation details, probably my approach with swaysock is wrong, because there is communication outside of it.
I thought of a way how sway and the child can share a common secret (randomly created), though the secret can be used to authenticate at swaysock. (I am swaylock, let me lock the screen) My only solution was a shared fd, because everything else can be readable by other processes (like env, parameters, ...). If sway has to open the fd, sway could do the authentication itself, so it would open swaysock and set the privileges for the new child.
The fd number will be passed as a string to the child as paramter (exec), so the child does not need to guess/rely on deterministic behaviour, to use the correct fd.
This also has the benefit that if the fd is not provided, the child can exec itself through sway swaymsg exec-with-fd /path/to/myself params and sway will add the fd (either through a replacement like {}, or at the end).
It is important, that sway is executing the child, so LD_PRELOAD and other stuff can not get inbetween and can not write to the privileged fd. Any thoughts on this?
wlr-protocols has migrated to gitlab.freedesktop.org. This pull request has been moved to:
https://gitlab.freedesktop.org/wlroots/wlr-protocols/-/merge_requests/27