Proxying Wayland for security

[Alyssa Ross]

Carsten Haitzler <raster at rasterman.com> writes:

> On Tue, 27 Jul 2021 19:29:45 +0000 Alyssa Ross <hi at alyssa.is> said:
>
>> 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.
>> 
>> 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.  
>
> The above is intended to be the job of the compositor. I would expect
> compositors to implement this. The only decisions to be made is which clients
> do they "lock down" and ask questions for (eg like allow copy yes/no) and which
> they do not. The compositor has a socket to the client and can use that to
> figure out all about the client that it wants to.
>
>> 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.
>
> You could - but then the compositor thinks your proxy is the client, not the
> actual client. This leads to lots of un-fun like if a compositor uses the
> client socket to query what PID and then what executable etc. that is and does
> things like shows icons based on the executable found (what desktop file that
> maps to) etc. ... If the compositor implements some kind of load balancing of
> rendering/updates based on PID. e.g. it may renice the PID of the client based
> on if its on a visible virtual desktop or not. I can go on...
>
>> Which brings me to the reason I'm bringing this all up on
>> wayland-devel.  I'd be grateful for any input about this idea,
>> especially:
>> 
>>  * Is this a sensible idea?  Is there something I haven't considered
>>    which would make this unworkable, and force me to do a
>>    compositor-specific implementation instead?
>
> See above. I can come up with more things that will be problematic. Sure. it
> *CAN* be done. In some cases like a "vnc proxy" whose job it is to display
> remote clients it deals with over vnc to a local wayland compositor... it's
> pretty much necessary. The above socket -> pid -> exe etc. isn't going to be
> valid/useful and you can't really do that due to the real client being "off
> machine". But for the vast vast majority of cases, they will be real  local
> clients with real PIDs etc.

A further thought I've just had -- the pid lookup is generally done
through libwayland-server's wl_client_get_credentials(), right?  So if
libwayland-server could be taught about the proxy, and the proxy could
communicate the pid/uid/gid to libwayland-server somehow, that could
make this possible after all, right?

(Assuming that the small amount of extra complexity in libwayland-server
was judged to be worth it to allow this degree of compositor-independent
add-on functionality, of course.)
-------------- 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/af8c14d5/attachment-0001.sig>