Proxying Wayland for security

Thu Jul 29 12:38:55 UTC 2021

On Thu, 29 Jul 2021 11:55:33 +0300 Pekka Paalanen <ppaalanen at gmail.com> said:

> On Wed, 28 Jul 2021 17:14:11 +0000
> Alyssa Ross <hi at alyssa.is> wrote:
> 
> > Pekka Paalanen <ppaalanen at gmail.com> writes:
> > 
> > > On Wed, 28 Jul 2021 11:06:43 +0000
> > > Alyssa Ross <hi at alyssa.is> 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.
> > >> 
> > >> [1]: https://github.com/bugaevc/wl-clipboard/  
> > >
> > > Hi,
> > >
> > > I believe wl-clipboard only works, because we suck at implementing what
> > > we intended in compositors. Once compositors get fixed to correctly
> > > track and check input event serials, pasting will not be possible
> > > without the client in question getting an explicit input event.
> > > Furthermore, as sending input events from Wayland clients is generally
> > > not possible, the input must come from a source the compositor trusts -
> > > mostly likely from the human user.
> > >
> > > You can't get input events with legit serials without a visible window.
> > >
> > > Merely getting window (keyboard) focus should not be enough, there
> > > needs to be a proper input event like button, key or touch down.
> > > Pointer motion does not count either, nor do keys already down when
> > > gaining keyboard focus.
> > >
> > > I don't recall what the story for setting clipboard contents is.  
> > 
> > Thank you for the correction.  Tt's still the case, though, that even
> > with a strict implementation, interacting with an application through a
> > mouse click or keyboard input would give it access to clipboard
> > contents.  That's not at all obvious to users, and I don't think it's
> > something I could justify in a security-focused system, so I do still
> > need to do something about it.
> 
> Yes.
> 
> I believe the reason it was designed like this is because only the
> app/client knows what actions in that app should cause "paste". There
> could be a menu entry to select, a button to click, a key-combo to hit.
> Or maybe you are in a VR space and stabbing a tin can with a dagger is
> the equivalent to "paste".
> 
> If you have a "are you sure you want to paste" dialog pop up every time
> an end user wants to paste something, I would bet the user will soon
> seek to let that app do pastes without asking. Then you are back at
> what Wayland intended to begin with.

That would be pretty nuts. It'd be more like ask once then flag that app as
approved (dialog probably even has "no" "just this once" "as long as this app
keeps running" "forever - always allow in future" options somewhere so the user
is really approving for how long they want to approve for.

To approve "forever" you do need some way to identify THIS client specifically
again in future. Something that then cannot be easily faked (e.g. imagine every
app in future has some 1024bit UUID or such generated the first time it is
launched by some launcher and forever after that, that app in that context
uses that UUID and advertises it to the compositor - well behaved clients then
get ongoing behavior across sessions. Bad clients that ignore this get reset
when they die and reconnect. As it's a massive UUID its not able to be faked
and it is somehow stored so malicious clients can't harvest someone else's
UUID).

So given the general view that sandboxed clients are untrusted, the sandboxing
mechanism can store the UUID inside the sandbox only that client can access.
Regular apps just have the UUID stored in ~/.config somewhere which the
sandboxed clients cannot read.

> How do you intend to handle or waive that problem?
> 
> 
> > > Did you check
> > > https://github.com/mupuf/libwsm ?
> > >
> > > That was linked from the Weston issue. I don't know if it applies, and
> > > as you can see, it never took off and has been dormant for years.  
> > 
> > I only just saw it -- thanks for bringing it to my attention.  It looks
> > like it could do the job, but it also looks like it would be difficult
> > to implement in compositors, since they seem to be responsible for
> > prompting the users for permission / notifying them of things that have
> > happened.
> > 
> > Since this morning, I've been thinking about investigating polkit for
> > this, since this is (at least roughly) within its scope, it's already
> > present on just about every free desktop system, and desktop
> > environments already have the appropriate integrations with it.
> 
> The me to first and foremost problem is what Simon McVittie wrote:
> How do you define and recognise a client's identity.
> 
> 
> Thanks,
> pq

-- 
------------- Codito, ergo sum - "I code, therefore I am" --------------
Carsten Haitzler - raster at rasterman.com