riya khanna
2014-09-24 04:34:46 UTC
(Please pardon multiple emails, artifact of merging all separate
conversations)
Thanks for your feedback!
Letting the kernel know about what devices a container could access (based
on device cgroups) and having devtmpfs in the kernel create device nodes
for a container that map to corresponding CUSE nodes is what I thought of.
For example, "echo 29:0 > /proc/<pid>/devices" would prepare a virtual
framebuffer (based on real fb0 SCREENINFO properties) for this process
provided permissions allow this operation. To view the framebuffer, the
CUSE based virtual device would talk to the actual hardware. Since
namespaces would have different view of the underlying devices, "sysfs" has
to made aware of this as well.
Please let me know your inputs. Thanks again!
-Riya
(well,
frightening
cuse-based
broad
container. Even for an unprivileged container it could connect to
bind-mounts of say /dev/null etc for any passthrough access.
the
like a
100000
be
through
with.
make
couldn't create device nodes though.
Yeah, but since he did mention cuse I thought I'd throw out a warning.
With fuse it is technically possible to have device nodes, but it's
usually prevented for unprivileged users by the suid helper (fusermount)
adding MS_NODEV to the mountflags. With my patches for fuse in user
namespaces the kernel will add nodev for any userns mount, and from a
security perspective I don't see any way around that.
Seth
_______________________________________________
lxc-devel mailing list
http://lists.linuxcontainers.org/listinfo/lxc-devel
conversations)
Thanks for your feedback!
Letting the kernel know about what devices a container could access (based
on device cgroups) and having devtmpfs in the kernel create device nodes
for a container that map to corresponding CUSE nodes is what I thought of.
For example, "echo 29:0 > /proc/<pid>/devices" would prepare a virtual
framebuffer (based on real fb0 SCREENINFO properties) for this process
provided permissions allow this operation. To view the framebuffer, the
CUSE based virtual device would talk to the actual hardware. Since
namespaces would have different view of the underlying devices, "sysfs" has
to made aware of this as well.
Please let me know your inputs. Thanks again!
-Riya
Hi,
I'm a newbie trying to come up with a fuse/cuse-based solution to
device namespace virtualization.
Fwiw I find the thought of allowing use of cuse from a containerI'm a newbie trying to come up with a fuse/cuse-based solution to
device namespace virtualization.
an unprivileged container at least) more than a little bit
from a security perspective. If a process does an ioctl on a
device then the process implementing the device can get a very
ability to read and write in the initiator's address space. If the
The cuse or fuse process would best run with the permissions of thecontainer. Even for an unprivileged container it could connect to
bind-mounts of say /dev/null etc for any passthrough access.
device were to show up automagically in devtmpfs and a process on
host could be tricked into opening the device, then that sounds
great vector for an attack. Just something to keep in mind.
Yup. You'd like to think that having the devices be owned by uidwould be a clue, but a script might not notice. The fs should only
mounted in the container's fs, but that can of course be reached
/proc/pid/root. Now an unpriv user shouldn't be able to chroot into
there without starting a new user namespace - leaving the victim no
long privileged and so no more harmful than the user was to begin
there without starting a new user namespace - leaving the victim no
long privileged and so no more harmful than the user was to begin
I don't think it matters if the user is unprivileged if you're using
cuse to implement the devices. In order for it to work the unprivileged
user would need read/write access to /dev/cuse, and once it has that
there seems to be no restrictions on what cuse functionality it can
cuse to implement the devices. In order for it to work the unprivileged
user would need read/write access to /dev/cuse, and once it has that
there seems to be no restrictions on what cuse functionality it can
use of.
When the user creates a device cuse calls device_add() for the new
device, which is going to create a node in devtmpfs which is owned by
global root. At that point I see nothing that would stop a process in
the host from opening the file and doing ioctls. It looks like it would
even be possible to use cuse to claim a well-known major/minor pair for
your device if it wasn't already claimed (e.g. the driver was a module
and not loaded).
I didn't spend a lot of time looking at the code, so it's possible I
missed something, but if I didn't then giving unprivileged users access
to /dev/cuse seems like a very bad idea.
Ok, agreed. The original author mainly mentioned fuse. I thought fuseWhen the user creates a device cuse calls device_add() for the new
device, which is going to create a node in devtmpfs which is owned by
global root. At that point I see nothing that would stop a process in
the host from opening the file and doing ioctls. It looks like it would
even be possible to use cuse to claim a well-known major/minor pair for
your device if it wasn't already claimed (e.g. the driver was a module
and not loaded).
I didn't spend a lot of time looking at the code, so it's possible I
missed something, but if I didn't then giving unprivileged users access
to /dev/cuse seems like a very bad idea.
couldn't create device nodes though.
With fuse it is technically possible to have device nodes, but it's
usually prevented for unprivileged users by the suid helper (fusermount)
adding MS_NODEV to the mountflags. With my patches for fuse in user
namespaces the kernel will add nodev for any userns mount, and from a
security perspective I don't see any way around that.
Seth
_______________________________________________
lxc-devel mailing list
http://lists.linuxcontainers.org/listinfo/lxc-devel