general high-level discussion about spectrum
 help / color / mirror / Atom feed
From: Alyssa Ross <hi@alyssa.is>
To: 7c6f434c@mail.ru, discuss@spectrum-os.org
Cc: aaron@ajanse.me, puck@puckipedia.com, talex5@gmail.com
Subject: Re: Proxying Wayland for untrusted clients
Date: Sat, 22 May 2021 15:08:47 +0000	[thread overview]
Message-ID: <87h7iuztz4.fsf@alyssa.is> (raw)
In-Reply-To: <E1lkRq9-0004ND-Us.7c6f434c-mail-ru@smtp48.i.mail.ru>

[-- Attachment #1: Type: text/plain, Size: 4162 bytes --]

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!

And yeah, with Wayland clients are already expecting to have to ask for
permission.  (I've just learned that this is actually done over DBus, so
the proxy would have to implement that as well, ugh.)  I suspect X11
clients wouldn't be very happy if it took them seconds to get the result
of their attempted screen capture, and users wouldn't be very happy if
screen sharing was just a blank box by default, rather than a permission
request.  (I'm not sure which of those would be possible with X11.)

>>monolithic, and each one would have to implement its own access
>>controls.  (Mutter already does this to some extent, at least for screen
>>sharing, I believe.)  The popular Wayland compositors are largely
>>focused on being feature-complete reimplementations of their X11
>>equivalents, and so taking advantage of the security features and access
>>controls the Wayland protocol makes possible hasn't been a priority for
>
> … 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.

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

>>inputs.  Additionally, the proxy would support a plugin interface,
>>through which the user of the proxy (or their distributor) could
>>configure custom behaviour.  This could be used to prompt the user for
>>confirmation before allowing a screen capture request, or even to
>>implement a similar thing for e.g. clipboard access, for which there is
>>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?

>>This approach would allow permissions systems and other custom Wayland
>>behaviour to be implemented in a compositor-independent manner.
>>Distributions which suppor tseveral compositors could implement
>>customisations in a single place, and users of compositors which lack
>>security features and the assurances memory-safety can provide against
>>untrusted input would gain access to those things.
>
> That surely sounds good…

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 832 bytes --]

  reply	other threads:[~2021-05-22 15:09 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 [this message]
2021-05-22 16:18   ` Michael Raskin
2021-05-22 17:22     ` Alyssa Ross
2021-05-22 18:48       ` Aaron Janse
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=87h7iuztz4.fsf@alyssa.is \
    --to=hi@alyssa.is \
    --cc=7c6f434c@mail.ru \
    --cc=aaron@ajanse.me \
    --cc=discuss@spectrum-os.org \
    --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).