[lxc-devel] device namespaces

[Serge Hallyn]

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.

Of course a new special mode for cuse isn't necessarily out of the question
either.

-serge