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

[Serge E. Hallyn]

On Sat, Jan 14, 2017 at 09:39:10AM +0700, Fajar A. Nugraha wrote:
> On Sat, Jan 14, 2017 at 4:56 AM, Fajar A. Nugraha <list at fajar.net> wrote:
> 
> > On Sat, Jan 14, 2017 at 3:52 AM, John <da_audiophile at yahoo.com> wrote:
> >
> >>
> >> 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?  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.
> >>
> >
> > There are several things that supports container security. Together, they
> > should provide "secure-enough" protection for practical use, so that anyone
> > with access to "normal*" containers can't compromise the host:
> >
> > - "classic" mount/pid/network/uts namespace, used by all container
> > implementation
> > - kernel security module (lxd in ubuntu enforce apparmor by default, while
> > openshift in redhat enforce selinux)
> > - disable "real" root (uid 0) in the container (lxd in ubuntu use user
> > namespace, while openshift in redhat prevents using root inside the
> > container by default)
> > - other things I might forgot, like seccomp and linux capabilities
> >
> >
> 
> To add an example: in the case of user namespaces + overlayfs bug, apparmor
> should already prevent it in the default lxd setup, since by default
> apparmor policy for container is to only allow special type of mounts (like
> mounting tmpfs).
> 
> So to answer your original question, I believe enabling userns in the
> kernel should be safe (from
> potential-attacker-only-have-ssh-access-to-the-container-but-not-the-host
> point of view) as long as you also have apparmor enabled. lxc/lxd CAN work
> without apparmor (as in the case of installing lxc/lxd on centos), but in
> that case you'd lose some of the security protection.

Indeed in general the container workloads will be protected by extra
layers.  That's not necessarily where the more serious concern comes in
though.  The concern is about the fact that unprivileged users on the host
can create a new user namespace without those extra layers, and exploit the
complications.  The new sysctl to disable unprivileged creation of user
namespaces is inteded to help with that, as well as, when an 0-day has been
found, to temporarily disable the attack vector.  Of course that doesn't
help if a user creates a new userns and leaves it sitting until a new 0-day
has been found, then exploits that from his pre-existing userns.

So there are two "scary" scenarious.  One is where a web service in an
unprivileged container is running a dangerous workload on behalf of an
attacker.  This is scary because anyone can attack, but is somewhat
mitigated by defense in depth.  The other is where an unprivileged user on
localhost is attacking.  That's scary because he can completely avoid the
defense in depth, unless you're running a reasonably secured host to begin
with.  That would mean selinux in this case, because the apparmor model is
very explicitly about confining target network-facing services, not local
users.  On the other hand, you have to not trust your local users, if such
exist, for this to become an issues.  (Of course, as I like to remind
people, most any system, i.e.  a "single-user" android phone or amazon
instance, is one attack away from becoming a multi-tenant system).

-serge