Securing non-root X input

Dave Airlie airlied at gmail.com
Sun Jan 31 00:38:51 PST 2010


On Sun, Jan 31, 2010 at 5:13 PM, Dmitry Torokhov
<dmitry.torokhov at gmail.com> wrote:
> On Sat, Jan 30, 2010 at 06:35:47PM -0700, Matthew Wilcox wrote:
>> On Fri, Jan 29, 2010 at 11:45:46PM -0800, Dmitry Torokhov wrote:
>> > Hi Matthew,
>> >
>> > On Fri, Jan 29, 2010 at 04:24:38PM -0700, Matthew Wilcox wrote:
>> > > This tiny patch allows the X server to ask how many times the device has
>> > > been opened.  If it's more than one, the X server can ask the user what
>> > > they want to do about it.  For bonus points, the X server can also run
>> > > programs like lsof or fuser to find out which other processes have the
>> > > device open, and tell the user that information too.  At that point,
>> > > the sysadmin can call in the ICBM strike on the offending user.
>> > >
>> > > Does this approach work for everyone?
>> >
>> > I do not think so. What about the cases when event devices are
>> > legitimately opened by several processes, like this:
>> >
>> > [dtor at dtor-d630 work]$ ps aux | grep hald-addon-input
>> > root      1132  0.0  0.0  22200   824 ?        S    Jan22   0:29
>> > hald-addon-input: Listening on /dev/input/event7 /dev/input/event2 /dev/input/event1 /dev/input/event6 /dev/input/event0 /dev/input/event12 /dev/input/event4
>> > dtor     30424  0.0  0.0 102736   808 pts/3    S+   23:23   0:00 grep hald-addon-input
>> > [dtor at dtor-d630 work]$
>> >
>> > It might not be hald but some other daemon monitoring key presses
>> > (sleep, hibernate, wifi keys and switches, etc).
>> >
>> > If it was just about ensuring that only oneprocess accesses the device
>> > then we could just use EVIOCGRAB but as experience shows it is not a
>> > workable solution.
>>
>> Yes, that's right.  I didn't quite go far enough in my explanation
>> above ...  the X server can look around the system to see what trusted
>> daemons (running as either root or the same user as the one running X)
>> currently have the device open, and notify the user if there's additional
>> openers that it isn't expecting.
>>
>
> Then it will be constant race between X and the rest of the world with X
> pretty much always behind. Kind of like SELinux - as soon as try moving
> left or right the thing starts screaming at you...
>
>> Maybe we don't need a kernel patch to make this work after all, just
>> a suid helper for X that uses the code from lsof/fuser to list all the
>> current openers of /dev/input/eventN.
>>
>
> But what about the case where malicious user opens the devices after the
> X done its scan?

That can't happen since we remove privs from the previous users of the
node before starting the new X server via ConsoleKit or at least thats the plan,

The problem is only a user holding open the evdev device after they've lost
perms on the device.

Dave.

> mknod is a privileged operation, requiring CAP_MKNOD. Otherwise evcen
> current setup would be completely insecure if any user could just mknod
> in his home directory and snoop root's keypresses at console.

Its more the other devices the kernel might make, or udev. Not sure if
that ever happens though.

Dave.



More information about the xorg mailing list