Proxying Wayland for security

[Pekka Paalanen]

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.

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
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 833 bytes
Desc: OpenPGP digital signature
URL: <https://lists.freedesktop.org/archives/wayland-devel/attachments/20210729/91287364/attachment.sig>