Proxying Wayland for security

[Alyssa Ross]

Daniel Stone <daniel at fooishbar.org> writes:

>> 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.

That's true for screenshots, but it's not true for clipboard contents,
right?  As I understand it, any application can paste, with the only
restriction being that it has to be in the foreground at the time, and
wl-clipboard[1] seems to demonstrate that it's possible to fulfill that
requirement without being visible to the user at all.

[1]: https://github.com/bugaevc/wl-clipboard/

>> 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?

Because that requires work for every compositor, whereas a proxy would
have allowed it to be done just once, and then to work with all
compositors.  But Carsten's mail convinced me that a proxy is indeed
probably not a good idea, and I should instead pursue integrating these
existing policy mechanisms with some sort of compositor-independent
policy decision maker.

> Cheers,
> Daniel
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 832 bytes
Desc: not available
URL: <https://lists.freedesktop.org/archives/wayland-devel/attachments/20210728/88476cc0/attachment.sig>