Proxying Wayland for security

[Alyssa Ross]

Hi Carsten, thanks for the detailed reply.

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

Hmm, yes, that would be a shame.  In general, I saw the proxy as a way
to move some policy decisions out of the compositor.  It would still
technically be possible to do those sorts of things by having the
compositor asking the proxy to do it, but that would require buy-in from
compositors.

It's frustrating that there's no way to implement this sort of thing,
which doesn't feel particularly compositor-dependent, without
implementing it seperately for every compositor my users might want to
use.  Especially when it's likely not upstreamable to at least some of
them -- e.g. I doubt Sway, which AIUI aims to avoid adding features
beyond what's needed for i3 compatibility, would be interested in it.
But I understand that that ship has probably sailed, and there's not
really anything I can do about it without breaking the expectations of
other things in the ecosystem.

>> 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.
>
>>  * Is this something that would be likely to be generally useful,
>>    outside of our project?  Would it make sense as something to
>>    collaborate on / have as a freedesktop.org project?
>
> What I think would be of value is a standardized method to decide which wayland
> clients should be locked down and which should not be. This is currently
> "undecided". Something a compositor can easily look up given the client socket
> and then decide which protocol requests it will handle in which way.

Do I understand correctly that you're saying you'd like there to be some
sort of oracle, outside of the compositor, that the compositor could ask
what restrictions should be applied to a client?

>> [1]: https://spectrum-os.org/
-------------- 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/88f62130/attachment.sig>