Re: Proxying Wayland for untrusted clients

Aaron Janse
2021-05-22T18:49:53Z

> This proposal turns the overall system of policy enforcement from what
> is currently a nice single centralized component (the compositor) with
> global observation, total visibility, total control, and nice
> non-distributed-system guarantees on message ordering, delivery, etc.
> into a decentralized and distributed system without those guarantees,
> subject to all manner of race conditions, etc. This makes it much
> harder to guarantee that intended policies are indeed enforced in the
manner expected.

How would the new system be distributed? My understanding is that it would just be a single process alongside the compositor.

> I actually think the scope is fairly limited?

Agreed, and I don't see a way to implement Spectrum without something like this. At a bare minimum we'd need a proxy for window decorations, unless we feel comfortable forking an existing window compositor.

I'm on mobile so I can't quote easily (I also have trouble reading hard-wrapped emails here), but we do have to place trust somewhere, and writing our own compositor would be too difficult, so it makes sense to have a simple parse/encode system if only to prevent special extensions that we don't recognize.

- Aaron

On Sat, May 22, 2021, at 10:22 AM, Alyssa Ross wrote:
> Michael Raskin <7c6f434c@mail.ru> writes:
>
> >>>>One of the benefits that Wayland is supposed to have over X11 is
> >>>>security. A Wayland application isn't supposed to be able to record the
> >>>>screen without user permission, for example. But in most compositors,
> >>>>it can, with no restrictions. Existing Wayland compositors are
> >>>
> >>> … and theoretically, an X server could feed empty capture to a client it
> >>> does not like …
> >>>
> >>> (of course with literal decades of actual backwards compatibility, X11
> >>> protocol has accumulated enough extensions that assigning permissions
> >>> to all of them might be somewhat painful)
> >>
> >>Considering that the world has convered on a single X server
> >>implementation, and it's apparently pretty horrible to maintain, I'm not
> >>sure I feel very positive about the idea of a custom one!
> >
> > Considering how much works fine in Xvnc which kind of lacks half the
> > extensions, and considering that all the bad hardware stuff now needs to
> > be handled in each compositor, it is unclear how much worse it would
> > actually be.
> >
> > So OpenGL-first design sounds like the real reason for all the mess.
>
> What do you mean by bad hardware stuff? Most hardware should be handled
> by KMS and libinput, shouldn't it?
>
> >>> … unsurprisingly, as these are typically WM teams who are now deprived
> >>> of what Xorg server did for everyone.
> >>
> >>Only the ones that don't use wlroots, I think. wlroots has its own
> >>problems, but in large part those are the problems we're trying to
> >>mitigate here.
> >
> > Yes, but it seems memory-unsafe even by the «careful C» standards, and
> > it seems to crash noticeably often with reasonably well-behaved clients,
> > so just a protocol compliance filter would not be enough.
>
> My experience with wlroots has been that when it crashes, it's because
> of quirks with monitor state and stuff, not anything from the Wayland
> protocol. Have you had a different experience?
>
> Another thing the proxy would be really cool for that I didn't mention
> before is debugging. Potentially you could even record and replay
> Wayland messages, which would help with any crash that was from Wayland.
>
> >>>>To solve these problems, I propose a proxy program that sits between
> >>>>Wayland clients and the compositor, in the same privelege domain as the
> >>>>compositor. The proxy would decode and re-encode every Wayland request
> >>>>(client->compositor message), and would discard any request it didn't
> >>>>understand. This would mitigate the problem of a large, privileged
> >>>>program written in a memory-unsafe language being exposed to untrusted
> >>>
> >>> Presumably, also validating that the shared memory buffers passed around
> >>> have the same size and protection as promised?
> >>
> >>Aren't shared memory buffers usually handed out by the compositor, to
> >>the client? IIRC this was the reason virtio wayland can work when it
> >>only supports shared memory that was allocated by the host.
> >
> > Looks like for wl_shm the client creates and shm object and sends FD to
> > the server, then both sides mmap from there. Given that one could cook
> > an FD with approximately arbitrary combination of properties, I guess
> > some care should be taken about this, too.
>
> Hmm, yes, looks like you're right. I wonder how virtio wayland can work
> the way it does, then... But yes, that is something we could validate.
>
> >>>>no support in the Wayland protocol. It could even be used to modify
> >>>>surfaces, to implement things like Qubes-style unspoofable coloured
> >>>>window borders.
> >>>
> >>> I am tempted to ask how close it will be to providing a socket for WM
> >>> and window decorator implementation (with some suitably limited
> >>> compositor as the backend behind the proxy).
> >>>
> >>> (So basically, defining a scope will be hard, and defining a scope in
> >>> a usefully extensible way might be even harder)
> >>
> >>I don't understand this point. Can you rephrase / expand?
> >
> > Well, you start describing a proxy that is basically «only valid
> > messages pass» and that's it, then add that it could also implement some
> > more functionality. Then you say plugins for policy-heavy functionality.
> > (I guess at that point the natural next step is a socket so that
> > safety-handling and user logic could be in different processes)
> >
> > This sounds like a recipe for scope creep, although it might also be
> > good as a single well-vetted Thing being safety-critical and a lot of
> > policy decisions being pushed to restartable and
> > functionality-restricted separate processes is actually better than the
> > current recommended approach to Wayland compositors.
> >
> > If you want to try pushing the project to freedesktop, I suspect it is
> > a good idea to define how much scope you want to include into the pitch.
> > Although apparently they don't have any objections to hosting software
> > with heavy scope creep, when reaching for a high profile, it is a good
> > idea to set internal expectations before having to manage external ones.
>
> I actually think the scope is fairly limited?
>
> 1. Receive request
> 2. Validate request
> 3. Asynchronously run request through plugins (you're right that
> external processes are probably a better idea, although I worry about
> complexity and performance).
> 4. Forward request to compositor
>
> Attachments:
> * signature.asc