[lxc-devel] device namespaces

[riya khanna]

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

On Fri, Sep 12, 2014 at 8:41 AM, Seth Forshee <seth.forshee at canonical.com>
wrote:

> On Fri, Sep 12, 2014 at 01:31:00PM +0000, Serge Hallyn wrote:
> > Quoting Seth Forshee (seth.forshee at canonical.com):
> > > On Wed, Sep 10, 2014 at 07:58:30PM +0000, Serge Hallyn wrote:
> > > > Quoting Seth Forshee (seth.forshee at canonical.com):
> > > > > On Tue, Sep 09, 2014 at 12:20:46PM -0500, riya khanna wrote:
> > > > > > 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 container
> (well,
> > > > > an unprivileged container at least) more than a little bit
> frightening
> > > > > from a security perspective. If a process does an ioctl on a
> cuse-based
> > > > > device then the process implementing the device can get a very
> broad
> > > > > 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 the
> > > > container.  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
> the
> > > > > host could be tricked into opening the device, then that sounds
> like a
> > > > > great vector for an attack. Just something to keep in mind.
> > > >
> > > > Yup.  You'd like to think that having the devices be owned by uid
> 100000
> > > > would be a clue, but a script might not notice.  The fs should only
> be
> > > > mounted in the container's fs, but that can of course be reached
> through
> > > > /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
> with.
> > >
> > > 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
> make
> > > 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 fuse
> > 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
> lxc-devel at lists.linuxcontainers.org
> http://lists.linuxcontainers.org/listinfo/lxc-devel
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxcontainers.org/pipermail/lxc-devel/attachments/20140923/60c7c45f/attachment.html>