Proxying Wayland for security

[Alyssa Ross]

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.

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

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.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 832 bytes
Desc: not available
URL: <https://lists.freedesktop.org/archives/wayland-devel/attachments/20210728/8ef317f1/attachment.sig>