Quoting Daniel Smith (viscous.liq...@gmail.com): > On 10/18/2011 12:51 PM, Serge E. Hallyn wrote: > > Quoting Papp Tamas (tom...@martos.bme.hu): > >> On 10/18/2011 04:47 PM, Serge E. Hallyn wrote: > >>> http://wiki.ubuntu.com/UserNamespace > >>> > >>> I've got a few patches to send yet for tightening down some remaining > >>> privilege leaks, then we should be ready to start relaxing things to make > >>> them usable. This includes Eric's simple implementation of assigning a > >>> superblock to a user namespace. My current tree is at > >>> http://kernel.ubuntu.com/git?p=serge/linux-2.6.git;a=shortlog;h=refs/heads/userns > >>> > >>> (Please feel free to join in!) > >>> > >> When can be expected to be available in the stock kernel? > > Depends on how many people join in? :) > > > > I'm hoping they'll be somewhat usable (including basic VFS support) sometime > > during 2012. > > > > What do you need people to help with? I don't know how much I could help > but would be willing to take a look.
Heh, good question. At the moment, review and testing of patches on lkml would help. Right now we're trying to finish tightening up the namespace. So while it's ok if a task in a child user namespace can't get the access it should have to its own resources, it absolutely must not be able to get inappropriate acces or privilege to a resource it doesn't own. Like root in a child user namespace being able to write into /proc/sys files. So looking for more such leaks would be very helpful right now. Once we finish that (hopefully soon) we'll want to loosen up appropriate restrictions. But as a part of that, actually, one thing we need (as recently pointed out) is to do better code review and testing of kernel code which is currently only exposed to root. Things like mount code and per-fs superblock readers. In the past only root was supposed to be able to call into those, so the code was deemed not as sensitive and may have some remaining exploits. (NOte that as Eric pointed out this is a bit of a fallacy since userspace then just exposed that functionality to unprivileged users through setuid-root helpers; but still it was a standing assumption). Now that root in a container may be able to call those, since root in a container can actually be an untrusted user on the host, we want to make sure that feeding garbage to the superblock reader can't crash the host or, worse, lead to privilege escalation. AFAIK noone is yet working on this effort. thanks, -serge ------------------------------------------------------------------------------ The demand for IT networking professionals continues to grow, and the demand for specialized networking skills is growing even more rapidly. Take a complimentary Learning@Ciosco Self-Assessment and learn about Cisco certifications, training, and career opportunities. http://p.sf.net/sfu/cisco-dev2dev _______________________________________________ Lxc-users mailing list Lxc-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/lxc-users