Proxying Wayland for security

[Pekka Paalanen]

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.

> >> I could just implement this stuff in a compositor, but doing it with a
> >> proxy would mean that a known subset of the protocol could be used
> >> with any compositor, with appropriate access controls.  It would also
> >> be a reusable component that could be customised to have different
> >> access control policy depending on the needs of a distributor or user.  
> >
> > I think you'd be better off dealing with the problem at source.
> > libwayland-server already has a 'global filter' mechanism which allows
> > an arbitrary hook to decide which clients can and cannot see which
> > interfaces. This is used to advertise private protocols to trusted
> > clients: for example, Weston's UI and screenshot support are handled
> > by external clients, but we use the filter to ensure that _only_ those
> > clients can access those protocols, not arbitrary clients.

Btw. Weston doesn't actually use wl_display_set_global_filter(). Weston
creates an authorized Wayland connection and then forks the trusted
helper process giving the client end of the connection to the new
process. Unauthorized clients do see the privileged interfaces, but if
they try to bind, Weston disconnects them.

> >
> > Implementing a proxy just shifts this problem rather than solving it
> > once; every time someone adds a new protocol, you have to plumb it
> > through the proxy and add some kind of policy mechanism. But the
> > compositors themselves probably have their own policy mechanism, so
> > why not just reuse that?  
> 
> Because that requires work for every compositor, whereas a proxy would
> have allowed it to be done just once, and then to work with all
> compositors.  But Carsten's mail convinced me that a proxy is indeed
> probably not a good idea, and I should instead pursue integrating these
> existing policy mechanisms with some sort of compositor-independent
> policy decision maker.

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.


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/20210728/02184d06/attachment.sig>