Re: Technical and security implications of using gnome-shell on KMS+evdev

[Owen Taylor <otaylor redhat com>]

Hi Giovanni - 

As a general consideration, we need to be do move Wayland incrementally.
For 3.10, we want to be able to run GNOME either using X or Wayland. We
want people to be able to work on a Wayland-ized GNOME on existing
systems.

This is one reason I'm not convinced about depending on a system
compositor - fundamentally changing the way that virtual terminals and
sessions work on the system is not compatible with people developing new
versions of GNOME on existing distributions, and being able to log in
either to X or to Wayland.

The other reason is that a system compositor, especially one that is
forwarding events, inevitably involves more context switches, more
opportunities for latency.

The primary use case for user-switching and multiple sessions is family
members, and we shouldn't go overboard in engineering it to make it
ultra-secure. There are some considerable limits to the amount of
security that can be provided on a single system. Leaving aside things
like timing attacks that are present simply by sharing a CPU, consider
the following scenario:

 - I walk up to a computer, someone else is logged in
 - I go to their user menu, and select Switch User
 - I get switch to the login screen, I try to log in
 - On the first attempt, I mistype my password and get an error
 - The second attempt works and I log into my session

What really happened was that the session was trojaned to show a
simulation of GDM the first time, steal my password, and *then* switch
to GDM. A system compositor and secure key combinations can help prevent
this type of attack, but only the most security-aware users will
benefit.

It may still be interesting to explore a system compositor long-term,
but I'd rather we get things going first, incrementally, and had
something to benchmark against and compare security against. There are
some things we can do short-term to make things better - one thing that
Kristian suggested is that evdev could easily have a 'mute' ioctl that
would allow a privileged process - whether that's logind or something
dedicated - to control which users see events.

In terms of the dependency of Mutter on GTK+ - I really don't think we
have an immediate problem there. We need support X apps indefinitely, so
Mutter needs to continue acting as a window manager, needs to continue
linking to Xlib. So we can simply use the X backend for GTK+

What we would need to do upfront is change the primary event path, so
events could go:

 evdev => Mutter => Clutter
          Mutter => Native wayland application
          Mutter => XWayland => X application
                             => Mutter => GTK+

So most events would *not* do a round-trip loop through the X server,
just events on a GTK+-implemented menu or other UI like that.

Over time we could then reduce our dependency on GTK+ by using native
Clutter UI for menus, reading settings directly from GSettings and so
forth, and eventually we could perhaps avoid connecting to X at all
until we had a native client to manage, but I don't really see a reason
to do this upfront. Do you see a problem with continuing to use the GTK+
version of X in the short-term?

- Owen