Suspending access to opened/active /dev/nodes during application runtime

Problem:
Has anyone thought about a mechanism to limit/remove an access to a
device during an application runtime? Meaning we have an application
that has an open file descriptor to some /dev/node and depending on
*something* it gains or looses the access to it gracefully (with or
without a notification, but without any fatal consequences).

Example:
LXC. Imagine we have 2 separate containers. Both running full operating
systems. Specifically with 2 X servers. Both running concurrently of
course. Both need the same input devices (e.g. we have just one mouse).
This creates a security problem when we want to have completely separate
environments. One container is active (being displayed on a monitor and
controlled with a mouse) while the other container runs evtest
/dev/input/something and grabs the secret password user typed in the
other.

Solutions:
The complete solution would comprise of 2 parts:
- a mechanism that would allow to temporally "hide" a device from an
open file descriptor.
- a mechanism for deciding whether application/process/namespace should
have an access to a specific device at a specific moment

Let's focus on the first problem only, as it would need to be solved
first anyway.  I haven't found anything that would allow me to do
it. There are a lot mechanisms that make it possible to restrict an
access during open():
- DAC
- ACL (controlled by hand or with uaccess)
- LSM (in general)
- device cgroups
But all of those can't do a thing when the device is already opened and
an application has a file descriptor.  I don't see such mechanism in
kernel sources either.

I do imagine that it would not be possible for every device to handle
such a thing (dri comes to mind) without breaking something (graphics
card state in dri example). But there is class of simple input/output
devices that would handle this without problems.

I did implement some proof-of-concept solution for an evdev driver by
allowing or disallowing events that go to evdev_client structure using
some arbitrary condition. But this is far from a generic solution.

My proof-of-concept is somewhat similar to this (I just found it):
http://www.spinics.net/lists/linux-input/msg25547.html
Though a little bit wider in scope. But neither is flawless nor
generic.

Has anyone had any thoughts about a similar problem?


-- 
Regards
Havner

On Fri, 07.03.14 19:45, Lukasz Pawelczyk (havner@gmail.com) wrote:

Problem:
Has anyone thought about a mechanism to limit/remove an access to a
device during an application runtime? Meaning we have an application
that has an open file descriptor to some /dev/node and depending on
*something* it gains or looses the access to it gracefully (with or
without a notification, but without any fatal consequences).

logind can mute input devices as sessions are switched, to enable
unpriviliged X11 and wayland compositors.

Example:
LXC. Imagine we have 2 separate containers. Both running full operating
systems. Specifically with 2 X servers. Both running concurrently of

Well, devices are not namespaced on Linux (with the single exception of
network devices). An X server needs device access, hence this doesn't
fly at all.

When you enumerate devices with libudev in a container they will never
be marked as "initialized" and you do not get any udev hotplug events in
containers, and you don#t have the host's udev db around, nor would it
make any sense to you if you had. X11 and friends rely on udev
however...

Before you think about doing something like this, you need to fix the
kernel to provide namespaced devices (good luck!)

course. Both need the same input devices (e.g. we have just one mouse).
This creates a security problem when we want to have completely separate
environments. One container is active (being displayed on a monitor and
controlled with a mouse) while the other container runs evtest
/dev/input/something and grabs the secret password user typed in the
other.

logind can do this for you between sessions. But such a container setup
will never work without proper device namespacing.

Solutions:
The complete solution would comprise of 2 parts:
- a mechanism that would allow to temporally "hide" a device from an
open file descriptor.
- a mechanism for deciding whether application/process/namespace should
have an access to a specific device at a specific moment

Well, there's no point in inventing any "mechanisms" like this, as long
as devices are not namespaced in the kernel, so that userspace in
containers can enumerate/probe/identify/... things correctly...

Lennart

-- 
Lennart Poettering, Red Hat

On 7 Mar 2014, at 20:24, Lennart Poettering [off-list ref] wrote:

On Fri, 07.03.14 19:45, Lukasz Pawelczyk (havner@gmail.com) wrote:

quoted

Problem:
Has anyone thought about a mechanism to limit/remove an access to a
device during an application runtime? Meaning we have an application
that has an open file descriptor to some /dev/node and depending on
*something* it gains or looses the access to it gracefully (with or
without a notification, but without any fatal consequences).

logind can mute input devices as sessions are switched, to enable
unpriviliged X11 and wayland compositors.

Would you please elaborate on this? Where is this mechanism? How does it work without kernel space support? Is there some kernel space support I’m not aware of?

quoted

Example:
LXC. Imagine we have 2 separate containers. Both running full operating
systems. Specifically with 2 X servers. Both running concurrently of

Well, devices are not namespaced on Linux (with the single exception of
network devices). An X server needs device access, hence this doesn't
fly at all.

When you enumerate devices with libudev in a container they will never
be marked as "initialized" and you do not get any udev hotplug events in
containers, and you don#t have the host's udev db around, nor would it
make any sense to you if you had. X11 and friends rely on udev
however...

Before you think about doing something like this, you need to fix the
kernel to provide namespaced devices (good luck!)

Precisly! That’s the generic idea. I’m not for implementing it though at this moment. I just wanted to know whether anybody actually though about it or maybe someone is interested in starting such a work, etc.

quoted

course. Both need the same input devices (e.g. we have just one mouse).
This creates a security problem when we want to have completely separate
environments. One container is active (being displayed on a monitor and
controlled with a mouse) while the other container runs evtest
/dev/input/something and grabs the secret password user typed in the
other.

logind can do this for you between sessions. But such a container setup
will never work without proper device namespacing.

So how can it do it when there is no kernel support? You mean it could be doing this if the support were there?

quoted

Solutions:
The complete solution would comprise of 2 parts:
- a mechanism that would allow to temporally "hide" a device from an
open file descriptor.
- a mechanism for deciding whether application/process/namespace should
have an access to a specific device at a specific moment

Well, there's no point in inventing any "mechanisms" like this, as long
as devices are not namespaced in the kernel, so that userspace in
containers can enumerate/probe/identify/... things correctly…

True. My point is about kernel space implementation. Like I wrote. I haven’t seen anything like this in kernel source and I’m well away it should be done there.
I would just like to know if anybody is interested in this, if anybody started or would like to start such a thing.

I do understand that systemd/logind would only provide a mechanism for determining who should have an access and who shouldn’t (or to be more specific it would utilize some kernel space configuration like cgroups). But the work itself has to be done in kernel space.

-- 
Regards,
Havner



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

On Fri, 07.03.14 21:51, Lukasz Pawelczyk (havner@gmail.com) wrote:

quoted

quoted

Problem:
Has anyone thought about a mechanism to limit/remove an access to a
device during an application runtime? Meaning we have an
application that has an open file descriptor to some /dev/node and
depending on *something* it gains or looses the access to it
gracefully (with or without a notification, but without any fatal
consequences).

logind can mute input devices as sessions are switched, to enable
unpriviliged X11 and wayland compositors.

Would you please elaborate on this? Where is this mechanism? How does
it work without kernel space support? Is there some kernel space
support I’m not aware of?

There's EVIOCREVOKE for input devices and
DRM_IOCTL_SET_MASTER/DRM_IOCTL_DROP_MASTER for DRM devices. See logind
sources.

quoted

Before you think about doing something like this, you need to fix the
kernel to provide namespaced devices (good luck!)

Precisly! That’s the generic idea. I’m not for implementing it though
at this moment. I just wanted to know whether anybody actually though
about it or maybe someone is interested in starting such a work, etc.

It's not just about turning on and turning off access to the event
stream. It's mostly about enumeration and probing which doesn't work in
containers, and is particularly messy if you intend to share devices
between containers.

quoted

logind can do this for you between sessions. But such a container setup
will never work without proper device namespacing.

So how can it do it when there is no kernel support? You mean it could
be doing this if the support were there?

EVIOCREVOKE and the DRM ioctls are pretty real...

Lennart

-- 
Lennart Poettering, Red Hat
_______________________________________________
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/systemd-devel

Hi

On Fri, Mar 7, 2014 at 7:45 PM, Lukasz Pawelczyk [off-list ref] wrote:

Problem:
Has anyone thought about a mechanism to limit/remove an access to a
device during an application runtime? Meaning we have an application
that has an open file descriptor to some /dev/node and depending on
*something* it gains or looses the access to it gracefully (with or
without a notification, but without any fatal consequences).

Example:
LXC. Imagine we have 2 separate containers. Both running full operating
systems. Specifically with 2 X servers. Both running concurrently of
course. Both need the same input devices (e.g. we have just one mouse).
This creates a security problem when we want to have completely separate
environments. One container is active (being displayed on a monitor and
controlled with a mouse) while the other container runs evtest
/dev/input/something and grabs the secret password user typed in the
other.

Solutions:
The complete solution would comprise of 2 parts:
- a mechanism that would allow to temporally "hide" a device from an
open file descriptor.
- a mechanism for deciding whether application/process/namespace should
have an access to a specific device at a specific moment

Let's focus on the first problem only, as it would need to be solved
first anyway.  I haven't found anything that would allow me to do
it. There are a lot mechanisms that make it possible to restrict an
access during open():
- DAC
- ACL (controlled by hand or with uaccess)
- LSM (in general)
- device cgroups
But all of those can't do a thing when the device is already opened and
an application has a file descriptor.  I don't see such mechanism in
kernel sources either.

I do imagine that it would not be possible for every device to handle
such a thing (dri comes to mind) without breaking something (graphics
card state in dri example). But there is class of simple input/output
devices that would handle this without problems.

I did implement some proof-of-concept solution for an evdev driver by
allowing or disallowing events that go to evdev_client structure using
some arbitrary condition. But this is far from a generic solution.

My proof-of-concept is somewhat similar to this (I just found it):
http://www.spinics.net/lists/linux-input/msg25547.html
Though a little bit wider in scope. But neither is flawless nor
generic.

Has anyone had any thoughts about a similar problem?

Lennart and Greg have already answered most of this, few notes from me:
 * EVIOCREVOKE and DRM_SET_MASTER/DROP_MASTER are real. We use them.
They solve your problem for gfx and input devices.
 * EVIOCMUTE is *bad*. It is a privileged ioctl compared to
EVIOCREVOKE, so we've never merged it. It neither has major advantages
over revoke. So use EVIOCREVOKE.
 * A generic frevoke() syscall would solve all is, but is unlikely to
ever appear upstream.

Cheers
David