Proxying Wayland for security

[Jonas Ådahl]

On Wed, Jul 28, 2021 at 01:36:54PM +0000, Alyssa Ross wrote:
> Jonas Ådahl <jadahl at gmail.com> writes:
> 
> > On Wed, Jul 28, 2021 at 11:06:43AM +0000, Alyssa Ross wrote:
> >> Daniel Stone <daniel at fooishbar.org> writes:
> >> 
> >> >> 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.
> >> >
> >> > As you've noted, the core protocol doesn't offer any way to scrape
> >> > these contents without additional extension protocols, which are not
> >> > implemented by all compositors. Generally speaking, GNOME's Mutter and
> >> > Weston tend not to implement these protocols, and wlroots-based
> >> > compositors tend to implement them.
> >> 
> >> That's true for screenshots, but it's not true for clipboard contents,
> >> right?  As I understand it, any application can paste, with the only
> >> restriction being that it has to be in the foreground at the time, and
> >> wl-clipboard[1] seems to demonstrate that it's possible to fulfill that
> >> requirement without being visible to the user at all.
> >
> > Getting things from the clipboard is generally supposed to require an
> > interaction of some sort, e.g. a button press, key press, touch down,
> > etc, but it might be not properly implemented here and there.
> > wl-clipboard relies on this not being done good enough, and will
> > eventally stop working, unless there exist some global state like
> > clipboard manager protocol that bypasses any content restrictions that
> > wl_data_device and friends apply.
> 
> That's good to know, but even so, there's no way for the compositor to
> know that the interaction corresponds to a user intent to paste.  So an
> application could still abuse a mouseover, or just some unrelated typing
> in its window, to read the clipboard contents when the user wasn't
> expecting it to.

That is indeed not possible, and likely very hard to get right. E.g. a
simple click or arbitrary key press might mean intent to paste, e.g.
press a "Paste" button. It's far from only related to Ctrl+V.

Only solution I see is only allow clipboard for sandboxed clients, and
explicitly grant access on a per application basis via some dialog
querying the user, similar to how audio/camera/... is granted in
Flatpak.


Jonas