<div dir="ltr">(Please pardon multiple emails, artifact of merging all separate conversations)<br><br><div>Thanks for your feedback! <br><div class="gmail_quote"><div dir="ltr"><div><div><br>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. <br></div><br>Please let me know your inputs. Thanks again!<span class="HOEnZb"><font color="#888888"><br><br></font></span></div><span class="HOEnZb"><font color="#888888">-Riya<br></font></span></div><div class="HOEnZb"><div class="h5"><div class="gmail_extra"><br><div class="gmail_quote">On Fri, Sep 12, 2014 at 8:41 AM, Seth Forshee <span dir="ltr"><<a href="mailto:seth.forshee@canonical.com" target="_blank">seth.forshee@canonical.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div><div>On Fri, Sep 12, 2014 at 01:31:00PM +0000, Serge Hallyn wrote:<br>
> Quoting Seth Forshee (<a href="mailto:seth.forshee@canonical.com" target="_blank">seth.forshee@canonical.com</a>):<br>
> > On Wed, Sep 10, 2014 at 07:58:30PM +0000, Serge Hallyn wrote:<br>
> > > Quoting Seth Forshee (<a href="mailto:seth.forshee@canonical.com" target="_blank">seth.forshee@canonical.com</a>):<br>
> > > > On Tue, Sep 09, 2014 at 12:20:46PM -0500, riya khanna wrote:<br>
> > > > > Hi,<br>
> > > > ><br>
> > > > > I'm a newbie trying to come up with a fuse/cuse-based solution to<br>
> > > > > device namespace virtualization.<br>
> > > ><br>
> > > > Fwiw I find the thought of allowing use of cuse from a container (well,<br>
> > > > an unprivileged container at least) more than a little bit frightening<br>
> > > > from a security perspective. If a process does an ioctl on a cuse-based<br>
> > > > device then the process implementing the device can get a very broad<br>
> > > > ability to read and write in the initiator's address space. If the<br>
> > ><br>
> > > The cuse or fuse process would best run with the permissions of the<br>
> > > container.  Even for an unprivileged container it could connect to<br>
> > > bind-mounts of say /dev/null etc for any passthrough access.<br>
> > ><br>
> > > > device were to show up automagically in devtmpfs and a process on the<br>
> > > > host could be tricked into opening the device, then that sounds like a<br>
> > > > great vector for an attack. Just something to keep in mind.<br>
> > ><br>
> > > Yup.  You'd like to think that having the devices be owned by uid 100000<br>
> > > would be a clue, but a script might not notice.  The fs should only be<br>
> > > mounted in the container's fs, but that can of course be reached through<br>
> > > /proc/pid/root.  Now an unpriv user shouldn't be able to chroot into<br>
> > > there without starting a new user namespace - leaving the victim no<br>
> > > long privileged and so no more harmful than the user was to begin with.<br>
> ><br>
> > I don't think it matters if the user is unprivileged if you're using<br>
> > cuse to implement the devices. In order for it to work the unprivileged<br>
> > user would need read/write access to /dev/cuse, and once it has that<br>
> > there seems to be no restrictions on what cuse functionality it can make<br>
> > use of.<br>
> ><br>
> > When the user creates a device cuse calls device_add() for the new<br>
> > device, which is going to create a node in devtmpfs which is owned by<br>
> > global root. At that point I see nothing that would stop a process in<br>
> > the host from opening the file and doing ioctls. It looks like it would<br>
> > even be possible to use cuse to claim a well-known major/minor pair for<br>
> > your device if it wasn't already claimed (e.g. the driver was a module<br>
> > and not loaded).<br>
> ><br>
> > I didn't spend a lot of time looking at the code, so it's possible I<br>
> > missed something, but if I didn't then giving unprivileged users access<br>
> > to /dev/cuse seems like a very bad idea.<br>
><br>
> Ok, agreed.  The original author mainly mentioned fuse.  I thought fuse<br>
> couldn't create device nodes though.<br>
<br>
</div></div>Yeah, but since he did mention cuse I thought I'd throw out a warning.<br>
<br>
With fuse it is technically possible to have device nodes, but it's<br>
usually prevented for unprivileged users by the suid helper (fusermount)<br>
adding MS_NODEV to the mountflags. With my patches for fuse in user<br>
namespaces the kernel will add nodev for any userns mount, and from a<br>
security perspective I don't see any way around that.<br>
<span><font color="#888888"><br>
Seth<br>
</font></span><div><div><br>
_______________________________________________<br>
lxc-devel mailing list<br>
<a href="mailto:lxc-devel@lists.linuxcontainers.org" target="_blank">lxc-devel@lists.linuxcontainers.org</a><br>
<a href="http://lists.linuxcontainers.org/listinfo/lxc-devel" target="_blank">http://lists.linuxcontainers.org/listinfo/lxc-devel</a><br>
</div></div></blockquote></div><br></div>
</div></div></div><br></div></div>