Securing non-root X input

Securing non-root X input

[Matthew Wilcox]

Dave Airlie commented at LCA that the last obstacle to running X as a
regular user (instead of setuid) was getting revoke() to work on evdev
file descriptors so that the previous user can't snoop the keypresses /
mouse movements / etc of the current user.

I respectfully disagree that this is the correct approach; making sure
that legitimate apps behave correctly in the presence of revoke()
is a significant hurdle, and one I'm not sure we want to undertake.
It's also a pain in the arse to implement in the kernel, and may take
an unacceptable amount of time or space to work.

Another approach we discussed was to implement O_EXCL without O_CREAT.
ie fail the open if another process has the device open.  This turns
out to be a bad idea as there are legitimate use cases (eg debugging)
where we want it to work even if another process has the device open.

We also discussed using leases to ensure that a given task was the
exclusive opener of a device, but the current lease code only works on
regular files, and see the previous paragraph for cases where we don't
want that behaviour anyway.

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?

diff --git a/drivers/input/evdev.c b/drivers/input/evdev.c
index 258c639..c0e5ecf 100644
--- a/drivers/input/evdev.c
+++ b/drivers/input/evdev.c
@@ -567,6 +567,9 @@ static long evdev_do_ioctl(struct file *file, unsigned int cmd,
 
 		return input_set_keycode(dev, t, v);
 
+	case EVIOCGOPEN:
+		return evdev->open;
+
 	case EVIOCRMFF:
 		return input_ff_erase(dev, (int)(unsigned long) p, file);
 
diff --git a/include/linux/input.h b/include/linux/input.h
index 7be8a65..702ba54 100644
--- a/include/linux/input.h
+++ b/include/linux/input.h
@@ -62,6 +62,7 @@ struct input_absinfo {
 #define EVIOCSREP		_IOW('E', 0x03, int[2])			/* set repeat settings */
 #define EVIOCGKEYCODE		_IOR('E', 0x04, int[2])			/* get keycode */
 #define EVIOCSKEYCODE		_IOW('E', 0x04, int[2])			/* set keycode */
+#define EVIOCGOPEN		_IO('E', 0x05)				/* return open count */
 
 #define EVIOCGNAME(len)		_IOC(_IOC_READ, 'E', 0x06, len)		/* get device name */
 #define EVIOCGPHYS(len)		_IOC(_IOC_READ, 'E', 0x07, len)		/* get physical location */

-- 
Matthew Wilcox				Intel Open Source Technology Centre
"Bill, look, we understand that you're interested in selling us this
operating system, but compare it to ours.  We can't possibly take such
a retrograde step."

Re: Securing non-root X input

[Dmitry Torokhov]

Hi Matthew,

On Fri, Jan 29, 2010 at 04:24:38PM -0700, Matthew Wilcox wrote:
> 
> Dave Airlie commented at LCA that the last obstacle to running X as a
> regular user (instead of setuid) was getting revoke() to work on evdev
> file descriptors so that the previous user can't snoop the keypresses /
> mouse movements / etc of the current user.
> 
> I respectfully disagree that this is the correct approach; making sure
> that legitimate apps behave correctly in the presence of revoke()
> is a significant hurdle, and one I'm not sure we want to undertake.
> It's also a pain in the arse to implement in the kernel, and may take
> an unacceptable amount of time or space to work.
> 
> Another approach we discussed was to implement O_EXCL without O_CREAT.
> ie fail the open if another process has the device open.  This turns
> out to be a bad idea as there are legitimate use cases (eg debugging)
> where we want it to work even if another process has the device open.
> 
> We also discussed using leases to ensure that a given task was the
> exclusive opener of a device, but the current lease code only works on
> regular files, and see the previous paragraph for cases where we don't
> want that behaviour anyway.
> 
> 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.

-- 
Dmitry

Re: Securing non-root X input

[Matthew Wilcox]

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.

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.

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.

-- 
Matthew Wilcox				Intel Open Source Technology Centre
"Bill, look, we understand that you're interested in selling us this
operating system, but compare it to ours.  We can't possibly take such
a retrograde step."

Re: Securing non-root X input

[Dmitry Torokhov]

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

Re: Securing non-root X input

[Dave Airlie]

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

Re: Securing non-root X input

[Dmitry Torokhov]

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

Re: Securing non-root X input

[Matthew Wilcox]

On Sat, Jan 30, 2010 at 11:13:07PM -0800, Dmitry Torokhov wrote:
> > 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...

Only if it's done badly (eg whitelisting HAL and Devkit).  The algorithm
I proposed above (allow anything owned by root, and anything owned by
the same user that is running X) should be secure, and futureproof.
Ultimately, it's up to the distro to get this right.

-- 
Matthew Wilcox				Intel Open Source Technology Centre
"Bill, look, we understand that you're interested in selling us this
operating system, but compare it to ours.  We can't possibly take such
a retrograde step."

Re: Securing non-root X input

[Dmitry Torokhov]

On Sun, Jan 31, 2010 at 10:08:01AM -0700, Matthew Wilcox wrote:
> On Sat, Jan 30, 2010 at 11:13:07PM -0800, Dmitry Torokhov wrote:
> > > 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...
> 
> Only if it's done badly (eg whitelisting HAL and Devkit).  The algorithm
> I proposed above (allow anything owned by root, and anything owned by
> the same user that is running X) should be secure, and futureproof.
> Ultimately, it's up to the distro to get this right.
> 

Ah, OK then. Well, I don't think that we need any special support from
kernel then. If users could create device nodes on their own we'd be in
trouble right now, but since they can't by default we should be good.

-- 
Dmitry