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

["Jasper St. Pierre" <jstpierre mecheye net>]

On Wed, Apr 10, 2013 at 9:36 AM, Giovanni Campagna <scampa giovanni gmail com> wrote:

Hello, fellow gnome-shell developers,

Hi Giovanni,

 

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.

We have had two meetings with krh so far about the technical details of Wayland on GNOME -- one a few weeks ago, and a follow-up meeting yesterday. We talked briefly about this sort of stuff, but glad to see you have a take on it.

 

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.

Part of the new Wayland work with having Weston directly control KMS would be that Weston would also be able to use special hardware overlays, like supported YUV overlays and and the hardware cursor for acceptable surfaces.

The system compositor approach would mean that the system compositor would be involved in setting those surfaces, and that means that there's one or two approaches:

* The smarts are kept in mutter, and a protocol is developed to discover and set hardware overlays to specific buffers. This is not insurmountable, but we'd need to keep it flexible to prevent changing it when new hardware with new buffer formats come out.

* The smarts are in the system compositor, and a protocol is developed to relay the scene graph to the system compositor. It would use this scene graph information not to composite buffers itself, but simply to pick buffers to use for the overlay, and relay that information back to the system compositor so it can remove it from its buffers.

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.

Hm, I didn't think of this.

 

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

I believe it's used right now for Alt+Esc because we haven't bothered implementing a replacement, but yeah, I'm fine with removing all this code.

 

- resize popups -> should be easy to reimplement in clutter

Well, yeah.

- clipboard (in gnome-shell) -> would not work anyway, needs a wayland
clipboard implementation in mutter

- input methods (in gnome-shell) -> would not work anyway

IM in Wayland is still an open problem. We discussed this at length, and I'm not sure if we came to a clear resolution on whether doing it in the client or compositor is better, but I was a fan of the compositor approach where key events are sent to an IM through some protocol, and then the IM does everything it needs to and eventually sends the client a "text event".

 

- 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

So, native wayland clients will be client-side-decorated, and it's likely that we'll remove our own server-side decorations and instead reuse GTK+'s CSS decorations.The hard part here is the interactivity window decoration buttons -- GTK+'s CSD right now uses GTK+ buttons, but that confuses our drag tracking (according to Owen. I removed that code and nothing changed and couldn't reproduce the original bug, but I'll let him be the final decider of that).

Given that CSD will have to emulate server-side decorations on X, too, using _NET_WM_BEGIN_DRAG_OP for window dragging and so on, there's a "so crazy it might just work" option here: remove all of our own interactivity, and put GTK+ decorations in a separate process that has some loose communication with mutter to not confuse state tracking, making it sort of equivalent to CSD, except that the "C" is controlled more or less by mutter.

Menus are also interesting, but it might be able to be solved by this approach.

 

- xsettings and icon theme (in gnome-shell) -> again, this is hard to do without

? I think something got cut off there.

Given how well XSettings has worked out for us (KDE still doesn't have an implementation; they're welcome to), and given how we shuttle non-standard properties through XSettings (all of the "Gtk/" ones), it might be better not even standardizing this. In gnome-shell, we can read from gsettings directly, so it makes this is sort of more of a toolkit issue. I think having org.gtk.settings gsettings schemas shipped with GTK+ might be the easiest way going forward. Right now in the Wayland branch they just read from the various settings schemas around (org.gnome.desktop, org.gnome.settings-daemon.plugins.xsettings), which isn't really the greatest thing.

 

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.

Thanks for thinking about this, Giovanni!

 

Giovanni
_______________________________________________
gnome-shell-list mailing list
gnome-shell-list gnome org
https://mail.gnome.org/mailman/listinfo/gnome-shell-list

--
  Jasper