Proxying Wayland for untrusted clients

Alyssa Ross
2021-05-22T13:06:10Z

[-- Attachment #1: Type: text/plain, Size: 2922 bytes --]

I've been thinking a lot about this for a while, thanks to conversations
with Thomas and Puck, CCed here. I think it's time to put it into words
properly and start working towards making it happen.

One of the benefits that Wayland is supposed to have over X11 is
security. A Wayland application isn't supposed to be able to record the
screen without user permission, for example. But in most compositors,
it can, with no restrictions. Existing Wayland compositors are
monolithic, and each one would have to implement its own access
controls. (Mutter already does this to some extent, at least for screen
sharing, I believe.) The popular Wayland compositors are largely
focused on being feature-complete reimplementations of their X11
equivalents, and so taking advantage of the security features and access
controls the Wayland protocol makes possible hasn't been a priority for
them. Additionally, every popular Wayland compositor is written in a
memory-unsafe language, and this combined with the complexity of the
Wayland protocol, with all the extensions involved, presents a serious
concern to applications of Wayland that involve untrusted clients.

To solve these problems, I propose a proxy program that sits between
Wayland clients and the compositor, in the same privelege domain as the
compositor. The proxy would decode and re-encode every Wayland request
(client->compositor message), and would discard any request it didn't
understand. This would mitigate the problem of a large, privileged
program written in a memory-unsafe language being exposed to untrusted
inputs. Additionally, the proxy would support a plugin interface,
through which the user of the proxy (or their distributor) could
configure custom behaviour. This could be used to prompt the user for
confirmation before allowing a screen capture request, or even to
implement a similar thing for e.g. clipboard access, for which there is
no support in the Wayland protocol. It could even be used to modify
surfaces, to implement things like Qubes-style unspoofable coloured
window borders.

This approach would allow permissions systems and other custom Wayland
behaviour to be implemented in a compositor-independent manner.
Distributions which suppor tseveral compositors could implement
customisations in a single place, and users of compositors which lack
security features and the assurances memory-safety can provide against
untrusted input would gain access to those things.

I'd like to hear feedback here, but I think early in the life of this
idea we should also reach out to the broader Wayland community. I think
there's a lot of potential for this idea beyond Spectrum, and it would
be great if it could be something developed with input from a big
breadth of Wayland users. If we can do that, it might be sensible for
it to live at freedesktop.org? I'm not sure how that works.

Let me know what you all think. :)

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 832 bytes --]