Proxying Wayland for security

[Carsten Haitzler]

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.

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

> [1]: https://spectrum-os.org/
> 
> Alyssa Ross


-- 
------------- Codito, ergo sum - "I code, therefore I am" --------------
Carsten Haitzler - raster at rasterman.com