Proxying Wayland for security

[Alyssa Ross]

Pekka Paalanen <ppaalanen at gmail.com> writes:

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

There's a lot of space in between "have a dialog every time a user wants
to paste" and the current state of things.

If a compositor checked with polkit whether a given client was allowed
to paste, just for example's sake, it could potentially:

 * Refrain from asking again for a short amount of time, letting that
   client continue to paste in the meantime (auth_self_keep).

 * Be configured to always allow a client to paste from some other
   clients, but have to ask permission to paste from a non-allow-listed
   client.

 * Allow some clients to always paste, but not others.  Even this is not
   possible today.

In Qubes, an existing system with a respectably-sized userbase, using
the clipboard between security domains requires a user to first copy to
the security domain's clipboard, then copy from there to the global
clipboard (Ctrl-Shift-C), then switch to the target domain, copy from
the global clipboard into that security domain (Ctrl-Shift-V), and
finally paste into the target application.  Copying between applications
within a security domain works as normal, without any of these extra
steps.  This system seems to work well for them, and is similar to my
second example.  Copying between security domains is a rare enough
operation to justify some extra confirmation from the user to ensure
it's deliberate.

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

Doesn't Simon Ser's security contexts proposal[1] address that?

[1]: https://gitlab.freedesktop.org/wayland/wayland-protocols/-/merge_requests/68
-------------- 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/20210729/7a9a07a1/attachment.sig>