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

[Giovanni Campagna <scampa giovanni gmail com>]

Hello, fellow gnome-shell developers,

in the past few weeks I saw that we started laying the plans for
gradually moving gnome-shell to wayland, and it's my understanding,
based on some wiki pages, that we want to run it straight on KMS/DRM +
evdev.
I would like to call out for the potential security implications of
doing this, in particular on the evdev side: having an open handle to
an event char device, however obtained, allows to see all input events
in the system, including those from other sessions and virtual
terminals.
Currently weston handles this by simply refusing to pull events when
on a different virtual terminal, but this solution is not acceptable
for gnome-shell: we allow running arbitrary code from a variety of
places, such as DBus and extensions, so it would be easy for a logged
in attacker to keep logging events after the vt switch.
On the KMS/DRM side, the risk is not calling drmDropMaster after the
switch, thus keeping privileges that are enough to acquire the full
content of the screen from a different session. Again, weston solves
this assuming that the right message is sent to weston-launch, thus
relying on an unprivileged and untrusted process.

The simple solution to both these problems is to have a system
compositor running as root, which takes care to send events and accept
buffers from the appropriate session only. My idea is that this system
daemon would implement a small subset of the wayland API, enough to
deliver events, monitor configuration and to accept fullscreen buffers
ready for scanout.

There would be another advantage of using a system compositor, and
that brings us to the second part of my email: the relationship
between GDK and Clutter in the mutter process.
I can't find it right now, but I understood that, given gdk has no
KMS+evdev backend, it will keep using the X11 backend with xwayland.
This is of course hackish, with multiple steps that reinterpret
events.
Having a system compositor that talks wayland on the other hand would
allow to make gdk the bottommost abstraction layer. Clutter would use
the gdk backend, and mutter would learn to get events from gdk, by
creating foreign windows in the X11 case, and client-side windows when
running as a wayland server.
Alternatively, we can remove the gdk/gtk+ dependency completely.
For the record, mutter uses gtk+ for the following features:
- event retrieval -> need to split the X11 parts (propertynotify,
selectionnotify, configurerequest, etc.) from actual events, and then
we can pull the latter from Clutter
- tab/workspace popups -> not needed in gnome-shell, I'm ok if we say
users of libmutter have to reimplement them
- resize popups -> should be easy to reimplement in clutter
- clipboard (in gnome-shell) -> would not work anyway, needs a wayland
clipboard implementation in mutter
- input methods (in gnome-shell) -> would not work anyway
- window decorations and menus -> this is the hard part, as a
clutter/st reimplementation will probably regress them, and it's a lot
of code anyway
- xsettings and icon theme (in gnome-shell) -> again, this is hard to do without

Personally, I'm not yet convinced on which way can be the best, but I
hope this can be the start of a productive discussion.

Giovanni