[prev in list] [next in list] [prev in thread] [next in thread]
List: freedesktop-xorg
Subject: Re: Securing non-root X input
From: Dave Airlie <airlied () gmail ! com>
Date: 2010-01-31 8:38:51
Message-ID: 21d7e9971001310038y11a936f2g778f4a3119652692 () mail ! gmail ! com
[Download RAW message or body]
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.
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.
_______________________________________________
xorg mailing list
xorg@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/xorg
[prev in list] [next in list] [prev in thread] [next in thread]
Configure |
About |
News |
Add a list |
Sponsored by KoreLogic