[lxc-devel] device namespaces

[Seth Forshee]

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.