Quoting Seth Forshee ([email protected]): > 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. But that's just me babbling thinking through it. There may be other dangers. _______________________________________________ lxc-devel mailing list [email protected] http://lists.linuxcontainers.org/listinfo/lxc-devel
