[RFC] Input design

[Eamon Walsh]

Daniel Stone wrote:
> Hi,
> So, one of the reasons I've been very hesitant to put 1.3.99.0 out is my
> dissatisfaction with the current design of the input hotplugging.  I
> think I know how to fix it, however, and would appreciate comments from
> the other people bored enough to hack on input.
> 
>  * Too much onus on the client
>    Right now, we rely on an intelligent config client to get things
>    done: you cannot simply have the server add all devices, or do
>    something otherwise sensible.  This, IMO, is a big mark against us.
> 
>  * Why D-Bus is not our ideal IPC system
>    D-Bus is a very good idea, and there's not much wrong with the spec
>    per se[0], but the client library is, well, abhorrent.  Its worst
>    transgression is to repeatedly call assert() from a library, which is
>    a design decision and will not be changed.  Its API is also quite
>    horrible and awkward to use (see config.c and respeclaration).  The
>    excuse for this is that no-one ever uses plain C anymore, so we
>    should use the GLib/Qt bindings.  IOW, someone needs to write
>    libdbus-desuckified.
> 
>  * Security issues not even solved properly
>    Right now, we need someone to write a D-Bus authentication plugin to
>    map X servers to users, in order to come up with a sensible security
>    policy.  Plus, MPX kind of blows this out of the water.


D-Bus does have SELinux support[1].  I'm not sure if it comes with a 
general security framework for adding other auth plugins.

And there's ConsoleKit[2] that claims to provide "a framework for 
keeping track of the various users, sessions, and seats present on a 
system."  It looks as though it hooks up with the display manager, HAL, 
and D-Bus.


> 
> To recap, the reason I went with D-Bus is because adding input devices
> is a security concern.  Either you can steal someone's keystrokes, or
> overwrite your partition table with the PS/2 init sequence.  The way
> we've dealt with this previously has been to have security policy
> out-of-band (i.e. config file), and keeping that way seemed an appealing
> method of skirting the security issues that came with doing it over the
> wire.  Also, D-Bus's security policies are fundamentally aimed at 'who's
> sitting at the machine?', rather than 'who can access /tmp?', and this
> is a good thing.

I'm not sure about the /dev/hda thing, but for input protection the 
(well, one) solution is to label each input device based on its owner or 
session.

Windows are labeled based on the client that owns them, which in turn 
comes from the xauth data or the socket itself (getpeercred, etc.)  When 
an input event is about to be delivered to a client a check can be done 
using the labels of the window, input device, and destination client.

The window and client parts are nearly done in the framework, it's just 
a matter of labeling input devices.


> 
> Here's the proposed new approach:
>   * More server-centric configuration
>     The server should at least be aware of which input devices are
>     around it.  We can do this by adding HAL support to the server, and
>     having it enumerate input devices via HAL.  This way, it always
>     keeps a list of active input devices, and enabling them is just one
>     step away from enumerating.  This provides for an xcompmgr -a type
>     situation where the server can just DTRT for us.
> 
>   * Leverage synergies for the benefit of all market segments
>     Just making sure you're still paying attention.
> 
>   * Move from D-Bus back to wire protocol
>     So, if we have a list of devices (optionally filtered by the admin;
>     we'll have to provide some mechanism of filtering the list), our
>     interaction with the client moves from 'add/remove this device' to
>     'enable/disable' this device.  This is a relatively safe operation:
>     HAL won't let us trash someone's partition table by writing the PS/2
>     init sequence to /dev/hda.  Multi-user issues will require a
>     security policy; this should probably be dealt with via the
>     server-side security framework.  Right now, we already allow random
>     users to steal other peoples' pointers with MPX, so that issue needs
>     to be solved through the security framework anyway.


In a truly arbitrary situation where you have N servers, M seats, and X 
mice, and someone plugs in another mouse, which user owns the new 
pointer should probably come from ConsoleKit or some other external 
program that figures it out and then notifies the X server somehow, 
either in the hotplug notification, HAL information, or directly via X 
protocol.  This can be used place the pointer on the right screen and to 
label the device in the security framework.

A fallback could be to have the display manager tell the server some 
basic defaults at login time (all current and future mice get the label 
of the newly-logged in user).

But there definitely has to be a trusted notion of who owns what mouse 
and keyboard that comes from somewhere outside X.


> 
> I think we can do this reasonably quickly, and once that's settled down,
> we can start shoving the 1.3.99.x releases out.
> 
> Questions? Opinions?

[1] man dbus-daemon(1), scroll to bottom
[2] http://people.freedesktop.org/~mccann/doc/ConsoleKit/ConsoleKit.html



-- 
Eamon Walsh <ewalsh at tycho.nsa.gov>
National Security Agency