Hi, it's been a long time since I've done one of these, but so much interesting stuff happened this week, and there's been a bit of renewed interest in the project, that it _really_ needed an update. So here it is. As always when I'm not keeping up with TWiS, this update is limited to only things that happened in the last week, because otherwise it would just be far too long.
A problem I've been thinking about for a long time is Wayland access control. The Linux desktop ecosystem is moving towards access controls for most functionality through xdg-desktop-portal (which sadly doesn't seem to have a website). But it doesn't cover stuff that's part of the core Wayland protocol, like access to the clipboard. And some compositors (wlroots-based ones) provide extra Wayland protocols for things like screenshots. And up to now, Wayland compositors haven't really done any authorization for these potentially dangerous APIs.
(All of this is only really meaningful for sandboxed applications -- running in Flatpak or a Spectrum VM or something. Linux isn't really set up to do separation between processes running as the same user without namespaces.)
So earlier this week, I posted to the Wayland mailing list with an idea I'd been thinking about for a while, which was to place a proxy program in front of the Wayland compositor, that would intercept client->compositor requests and handle access control. I was quickly convinced that a proxy wasn't a good idea, but there was a lot of discussion, and it was really helpful to me figuring out what the right way to do it might be.
There are really two problems to be solved here, one of which I hadn't even thought much about. The first is securely identifying a Wayland client. A compositor needs to be able to form the question "Should client X be able to do this?", and to do that it needs to be able to identify a client as client X, and know if it tries to interact with client X later, that it'll be talking to the same client. In a non-virtualized system, the obvious way to do this would be getting the pid of the client from the connection socket and then looking it up in proc(5) to find out executable path, but this approach is fundamentally insecure.
The way forward here (and one that would work for Spectrum) appears to be the proposed Security Contexts protocol, which would allow a sandbox implementation to provide a security context identifier for a client before handing off the Wayland connection to the client. Once the security context had been set up, it wouldn't be allowed to be modified, so once the sandboxed client was given the connection, it wouldn't be able to change the security context identifier.
In Spectrum, the security context identifier here would likely be a unique, user-provided name for the VM, and the security context setup would be done by the virtio wayland implementation in the VMM.
The second part of this puzzle is how the compositor should decide whether a client should be allowed to perform a particular operation, like a paste or going fullscreen (which is risky because it might spoof a desktop).
There was actually a previous attempt at this a long time ago. libwsm (short for Wayland Security Module) was a library that compositors would have integrated to make authorization decisions. But it wasn't adopted by compositors, and it some things we now know to be bad ideas, like setting policy based on the executable path. It also made compositors responsible for any sort of authorization UI. In my opinion, it's better to have that done by the external piece, so that compositors have as little work to do as possible and therefore authorization is implemented as widely as possible.
The compositor could implement an authorization system entirely on its own, but this would be a lot of code for each compositor to write, and it would limit the user to whatever permissions system the compositor came up with, which might not be able to accommodate their needs. (An example of this would be a Spectrum user that wanted to allow pasting between two applications, but not allow pasting between either of those and any other application.)
It could also be implemented by having the compositors integrate with something like polkit, but compositor authors are reluctant to integrate directly with a single system like that, and even polkit might not support everything that would be desirable in an authorization system. (For example, it might be nice to implement libwsm's concept of a soft allow, where an action is permitted, but a notification is shown so the user is aware it's happened.)
So a third solution, suggested by ifreund, a Wayland compositor author, in the Spectrum IRC channel, would be to have a privileged Wayland client that the compositor could ask authorization questions to, with a new protocol. The compositor would know that this particular client should be privileged because it either wouldn't be in a security context, or would be given a special security context identifier known to the compositor ahead of time. Then, implementations of this protocol could do authorization however they wanted, with the only limitation being the questions the compositor was programmed to ask them. I think this is a good way forward, but it'd be important to discuss with more compositor authors before getting to excited about it.
Next steps from here with Wayland are:
* Figure out what needs to happen to move the security contexts proposal forward. If it needs an experimental implementation, maybe we could help with that?
* Inquire about the authorization protocol idea, and see how other compositor offers would feel about it. If there's a generally positive reaction, figure out how to move forward with it.
: https://github.com/flatpak/xdg-desktop-portal/ : https://lists.freedesktop.org/archives/wayland-devel/2021-July/041896.html : https://spectrum-os.org/lists/archives/spectrum-discuss/8735ueudel.fsf@alyss... : https://gitlab.freedesktop.org/wayland/weston/-/issues/206#note_176699 : https://gitlab.freedesktop.org/wayland/wayland-protocols/-/merge_requests/68 : https://www.freedesktop.org/software/polkit/docs/latest/polkit.8.html : https://github.com/mupuf/libwsm : https://email@example.com/
I created a branch in Spectrum's nixpkgs repository for the long-overdue merge with upstream, did the merge, and posted some patches to spectrum-devel that fix all the builds that broke as a result. I've been letting them sit for a few days hoping for a review. Once that's done, it's time for another chromiumOSPackages upgrade, but that should be pretty easy this time because we're only one version behind.
: https://spectrum-os.org/git/nixpkgs : https://spectrum-os.org/lists/archives/spectrum-devel/20210729100928.1965341...
Thanks for keeping up with Spectrum. :)