Re: Securing non-root X input

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

On Sun, Jan 31, 2010 at 06:38:51PM +1000, Dave Airlie wrote:
> On Sun, Jan 31, 2010 at 5:13 PM, Dmitry Torokhov
> <dmitry.torokhov@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@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?
> 
> 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.
> 

I see. How revoke will help here though? How will we know which
descriptors shoudl be revoked and which should be left alone?

> > 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.
> 

This is distro config and may happen now (udev creates a non-root device
if misconfigured etc).

-- 
Dmitry
--
To unsubscribe from this list: send the line "unsubscribe linux-input" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html