Passive and active attacks via X11. Is Wayland any better?

[Kristian Høgsberg]

On Fri, Feb 17, 2012 at 1:39 PM, Joanna Rutkowska
<joanna at invisiblethingslab.com> wrote:
> On 02/17/12 09:43, Tiago Vignatti wrote:
>> Hi,
>>
>> On 02/16/2012 08:36 PM, frqb4td wrote:
>>> In "The Linux Security Circus: On GUI isolation" (link:
>>> http://theinvisiblethings.blogspot.com/2011/04/linux-security-circus-on-gui-isolation.html
>>>
>>> ) - The Invisible Things Lab's blog, Joanna Rutkowska describes attacks
>>> from one X11 app on another and the general problem of the lack of
>>> GUI-level isolation, and how it essentially nullifies all the desktop
>>> security.
>>
>> well, she's initially totally missed the motivations of XACE initially
>> and designed her own "security" mechanism then. It doesn't sound quite
>> right in terms of research, just to begin with... anyways: "New comments
>> have been disabled for this post by a blog administrator." :(
>>
>
> Boo!
>
>>
>>> Can passive (snooping) attacks be avoided? The passive attack she
>>> describes certainly works on my system, though I note that one of the
>>> comments says gksudo input can't be snooped.
>>
>> Input delivery for Wayland clients works in a different way from the X:
>> while in X the events are broadcasted to all clients interested, on
>> Wayland this happens by the compositor choosing the correct client
>> surface (weston_compositor_pick_surface, on Weston). So I don't see any
>> way to a client sniff another with Wayland's current model. One could
>> eavesdrop UNIX sockets though, but that's a different story.
>>
>>
>>> Can active attacks (injecting keystrokes) be avoided? I seem to recall
>>> that active attacks was turned of by default a long time ago. But a
>>> quick google suggests that the XTest extension nullifies that (How to
>>> map a key-combination to a keyboard-button?).
>>
>> Wayland doesn't provide any way to inject artificial events at the
>> moment. But definitely it will be designed with security on mind. So
>> yeah, we're safe on this side now  as well :)
>>
>
> That's a very comforting statement! However, being a nasty person as I
> am, let me ask a few more questions:
>
> 1) Are you planning to support on-screen keyboard apps? If so, how this
> is going to be implemented, so that a malicious/compromised app couldn't
> act as such "on-screen keyboard" and inject keystrokes to other apps?

We can restrict access to functionality on a per-application basis.
An on-screen keyboard would be part of the core ui and launched by the
compositor in a way that gives it access to the "input event
injecting" interface.

> 2) Are you planning to support screenshot-taking apps, or
> jigsaw-puzzle-like screensavers? If so, how are you planning to prevent
> malicous/compromised apps from sniffing the content of other apps? E.g.
> I might not be happy seeing Tetris being able to take screenshots of my
> Thunderbird's windows and send them back to China...

No.  In general, clients don't have access to or even knowledge of any
other clients on the server.  They can't see other clients buffers or
any of the compositors front buffers.

We do have a screenshot example app that uses an example interface to
get a screenshot out of the server but that's only a demo and
something that we've explicitly enabled.  We might want to change that
to be triggered by a compositor hot-key to avoid setting a bad
example.

> 3) How is Wayland going to protect the clipboard from being
> sniffed/modified by 3rd party apps? E.g. I want to copy my bank password
> from KeepassX to Firefox, and don't want Tetris to be able to eavesdrop
> on that...

You only get access to the current selection when the application is
activated (receive keyboard focus).  If you don't want tetris to get
access to the clipboard at all, you have to be able to classify
clients as trusted or not, which is a bigger problem.  Actually
restricting access to the clipboard for an untrusted clients is a
small detail.  Ultimately, the clipboard is by definition for
inter-client communication and once you put something there, it's up
for grabs.  If you want a secure way to pass passwords between apps, I
suggest you don't use it.

Kristian