[lxc-users] Risk/benefit of enabling user namespaces in the kernel for running unprivileged containers

Serge E. Hallyn serge at hallyn.com
Sun Jan 29 16:29:31 UTC 2017


On Fri, Jan 13, 2017 at 08:52:14PM +0000, John wrote:
> 
> 
> 
> 
> ----- Original Message -----
> > From: Serge E. Hallyn <serge at hallyn.com>
> > To: LXC users mailing-list <lxc-users at lists.linuxcontainers.org>
> > Sent: Friday, January 13, 2017 11:20 AM
> > Subject: Re: [lxc-users] Risk/benefit of enabling user namespaces in the kernel for running unprivileged containers
> 
> >>  I'm unclear about several points:
> >>  *Is it true that enabling CONFIG_USER_NS makes LXCs safer but at the cost 
> > of decreasing security on the host?
> > 
> > "basically"
> > 
> > "decreasing security on the host" implies there are known 
> > vulnerabilities or
> > shortcomings which you are enabling as a tradeoff.  That's not the case.  
> > Rather,
> > there are so many interactions between types of resources that we keep running
> > into new ways in which unanticipated interactions can lead to vulnerabilities
> > when unprivileged users gain the ability to create new namespaces.
> > 
> > Some of the 'vulnerabilities' are pretty arguable, for instance the 
> > ability
> > for an unprivileged user to escape a negative acl by dropping a group, or to
> > see an overmounted file in a new namespace.  But others are very serious.
> > 
> > When that will settle down, noone really knows.
> 

Sorry, this got lost in my backlog.  Been bad about inbox 0.

> Again, thank you for the detailed reply.  Are the nature of these sorts of
> interactions such that users require physical access or ssh access to the
> host machine in order to exploit, or can they originate from within the
> container?

It dpeends.  The ACL one I mentioned above is only relevant for users who
have local (non-container) accounts, since the whole point is that they
get around an access restriction imposed on their local user.

One thing user namespaces do is allow root in a user namespace, which we
call untrusted, to run kernel code which previously was guarded so that
only the real trusted root could ever run it.  The classic example of this
is superblock readers which run when you mount a filesystem to parse its
metadata.  This in particular is still guarded because it's so unsafe, but
there are others.  (Just look for any code inside a 'if ns_capable()'
check).  If such code has a bug, then root in a container can exercise that
bug.

>   If it's a physical/remote access thing, no big deal assuming we
> do not open the host up to ssh, right?  If however the vector is the
> container itself, that's entirely different.

It can be the container itself - the question is who will exploit it.

Do you trust your local users?  Do you allow containers to run services
that are open to the world?  For instance if a container exports a web
app or a mysql service, then an attacker might exploit a mysql bug to
get access as the mysql user in the container, then run one kernel exploit
to become container, root, then exploit another kernel bug to do something
which only the host root should be able to do.

But I think (I've not looked over the list of known CVEs - i really need
to) most of the bugs have been more of the sort where a local non-root
user does something in a new user namespace, which he can create with
absolutely no privilege.

-serge


More information about the lxc-users mailing list