[lxc-devel] device namespaces

[Seth Forshee]

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