From: "Aaron Janse" <aaron@ajanse.me>
To: "Alyssa Ross" <hi@alyssa.is>, 7c6f434c@mail.ru, discuss@spectrum-os.org
Cc: puck@puckipedia.com, talex5@gmail.com
Subject: Re: Proxying Wayland for untrusted clients
Date: Sat, 22 May 2021 11:48:59 -0700 [thread overview]
Message-ID: <d7014143-d4e0-46d1-9894-59372119c2cb@www.fastmail.com> (raw)
In-Reply-To: <87eedyznsw.fsf@alyssa.is>
> 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
next prev parent reply other threads:[~2021-05-22 18:49 UTC|newest]
Thread overview: 11+ messages / expand[flat|nested] mbox.gz Atom feed top
2021-05-22 13:05 Alyssa Ross
2021-05-22 13:45 ` Michael Raskin
2021-05-22 15:08 ` Alyssa Ross
2021-05-22 16:18 ` Michael Raskin
2021-05-22 17:22 ` Alyssa Ross
2021-05-22 18:48 ` Aaron Janse [this message]
2021-05-22 20:00 ` Michael Raskin
2021-05-22 17:13 ` Jean-Philippe Ouellet
2021-05-25 11:40 ` Alyssa Ross
2021-05-22 17:52 Josh DuBois
2021-05-22 20:05 ` Michael Raskin
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=d7014143-d4e0-46d1-9894-59372119c2cb@www.fastmail.com \
--to=aaron@ajanse.me \
--cc=7c6f434c@mail.ru \
--cc=discuss@spectrum-os.org \
--cc=hi@alyssa.is \
--cc=puck@puckipedia.com \
--cc=talex5@gmail.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).