general high-level discussion about spectrum
 help / color / mirror / Atom feed
From: Alyssa Ross <>
Cc: Aaron Janse <>,
	Puck Meerburg <>,
	Thomas Leonard <>
Subject: Proxying Wayland for untrusted clients
Date: Sat, 22 May 2021 13:05:38 +0000	[thread overview]
Message-ID: <> (raw)

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

I've been thinking a lot about this for a while, thanks to conversations
with Thomas and Puck, CCed here.  I think it's time to put it into words
properly and start working towards making it happen.

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
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
them.  Additionally, every popular Wayland compositor is written in a
memory-unsafe language, and this combined with the complexity of the
Wayland protocol, with all the extensions involved, presents a serious
concern to applications of Wayland that involve untrusted clients.

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

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.

I'd like to hear feedback here, but I think early in the life of this
idea we should also reach out to the broader Wayland community.  I think
there's a lot of potential for this idea beyond Spectrum, and it would
be great if it could be something developed with input from a big
breadth of Wayland users.  If we can do that, it might be sensible for
it to live at  I'm not sure how that works.

Let me know what you all think. :)

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

             reply	other threads:[~2021-05-22 13:06 UTC|newest]

Thread overview: 11+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2021-05-22 13:05 Alyssa Ross [this message]
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
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:

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \ \ \ \ \ \ \

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