[Lxc-users] Launching init in a container as non-root

[Serge Hallyn]

Quoting Daniel Smith (viscous.liquid at gmail.com):
> On 10/18/2011 12:51 PM, Serge E. Hallyn wrote:
> > Quoting Papp Tamas (tompos at 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