Re: Securing non-root X input

[Dmitry Torokhov <dmitry.torokhov@gmail.com>]

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@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@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?

> My only concern is if users are permitted to create other names for a
> given device, lsof/fuser doesn't find that:
> 
> # ln -s /dev/input/event0 myev0
> # sleep 60 < myev0 &
> # lsof /dev/input/event0
> COMMAND    PID USER   FD   TYPE DEVICE SIZE/OFF NODE NAME
> sleep     2223 root    0r   CHR  13,64      0t0 1667 /dev/input/event0
> hald-addo 3363 root    6r   CHR  13,64      0t0 1667 /dev/input/event0
> devkit-po 3588 root    9r   CHR  13,64      0t0 1667 /dev/input/event0
> # rm myev0
> # mknod myev0 c 13 64
> # sleep 60 < myev0 &
> # lsof /dev/input/event0
> COMMAND    PID USER   FD   TYPE DEVICE SIZE/OFF NODE NAME
> hald-addo 3363 root    6r   CHR  13,64      0t0 1667 /dev/input/event0
> devkit-po 3588 root    9r   CHR  13,64      0t0 1667 /dev/input/event0
> 
> So if we need to catch that possibility, we need something like this
> kernel patch ... if we're confident that /dev/input/ will be the only
> name for a given event, we don't need a kernel patch to make this work.
> 

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.

-- 
Dmitry