Proxying Wayland for security

[Daniel Stone]

Hi Alyssa,

On Tue, 27 Jul 2021 at 20:30, Alyssa Ross <hi at alyssa.is> wrote:
> Hi!  I'm Alyssa and I'm working on Spectrum[1], which is a project
> aiming to create a compartmentalized desktop Linux system, with high
> levels of isolation between applications.

I've seen, it's neat!

> One big issue for us is protecting the system against potentially
> malicious Wayland clients.  It's important that a compartmentalized
> application can't read from the clipboard or take a screenshot of the
> whole desktop without user consent.  (The latter is possible in
> wlroots compositors with wlr-screencopy.)
>
> So an idea I had was to was to write a proxy program that would sit
> in front of the compositor, and receive connections from clients.  If
> a client sent a wl_data_offer::receive, for example, the proxy could
> ask for user confirmation before forwarding that to the compositor.

As you've noted, the core protocol doesn't offer any way to scrape
these contents without additional extension protocols, which are not
implemented by all compositors. Generally speaking, GNOME's Mutter and
Weston tend not to implement these protocols, and wlroots-based
compositors tend to implement them.

> I could just implement this stuff in a compositor, but doing it with a
> proxy would mean that a known subset of the protocol could be used
> with any compositor, with appropriate access controls.  It would also
> be a reusable component that could be customised to have different
> access control policy depending on the needs of a distributor or user.

I think you'd be better off dealing with the problem at source.
libwayland-server already has a 'global filter' mechanism which allows
an arbitrary hook to decide which clients can and cannot see which
interfaces. This is used to advertise private protocols to trusted
clients: for example, Weston's UI and screenshot support are handled
by external clients, but we use the filter to ensure that _only_ those
clients can access those protocols, not arbitrary clients.

Implementing a proxy just shifts this problem rather than solving it
once; every time someone adds a new protocol, you have to plumb it
through the proxy and add some kind of policy mechanism. But the
compositors themselves probably have their own policy mechanism, so
why not just reuse that?

Cheers,
Daniel