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

[Serge E. Hallyn]

On Fri, Jan 13, 2017 at 08:52:14PM +, John wrote:
> 
> 
> 
> 
> - Original Message -
> > From: Serge E. Hallyn 
> > To: LXC users mailing-list 
> > 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
___
lxc-users mailing list
lxc-users@lists.linuxcontainers.org
http://lists.linuxcontainers.org/listinfo/lxc-users

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

[John]

Thanks guys, for providing the context around this.
___
lxc-users mailing list
lxc-users@lists.linuxcontainers.org
http://lists.linuxcontainers.org/listinfo/lxc-users

Re: [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  wrote:
> 
> > On Sat, Jan 14, 2017 at 3:52 AM, John  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
___
lxc-users mailing list
lxc-users@lists.linuxcontainers.org
http://lists.linuxcontainers.org/listinfo/lxc-users

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

[Fajar A. Nugraha]

On Sat, Jan 14, 2017 at 4:56 AM, Fajar A. Nugraha  wrote:

> On Sat, Jan 14, 2017 at 3:52 AM, John  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.

-- 
Fajar
___
lxc-users mailing list
lxc-users@lists.linuxcontainers.org
http://lists.linuxcontainers.org/listinfo/lxc-users

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

[Fajar A. Nugraha]

On Sat, Jan 14, 2017 at 3:52 AM, John  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

So in short, if you're concerned about security, go with a container
implementation on a distro that actively supports it. Otherwise you'd end
up with reduced security (which might still be acceptable in some cases),
or have to change/configure/compile lots of things manually.

-- 
Fajar

* By "normal" here I'm referring to default unpriv container in lxd and
containers in redhat openshift as example.
___
lxc-users mailing list
lxc-users@lists.linuxcontainers.org
http://lists.linuxcontainers.org/listinfo/lxc-users

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

[John]

- Original Message -
> From: Serge E. Hallyn 
> To: LXC users mailing-list 
> 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.


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.
___
lxc-users mailing list
lxc-users@lists.linuxcontainers.org
http://lists.linuxcontainers.org/listinfo/lxc-users

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

[Serge E. Hallyn]

Quoting John (da_audioph...@yahoo.com):
> From S. Graber's blog[1] and other sources, consensus is that unprivileged 
> containers offer the best security from the container's perspective.  There 
> is quite a discussion in an Arch Linux feature request[2] around the risks of 
> enabling user namespaces in the distro default kernel as it applies to the 
> host OS as I understand it.  Ultimately, the Arch developers believe that it 
> is too much of a risk to implement, and this has been echoed as recently as 
> May of 2016[3].
> 
> 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.

> *Under what circumstances is that true if at all?
> *How contemporary are the arguments against enabling this option now in 2017 
> with Linux kernel v3.9.2 and lxc v2.0.6?

They're still relevant.

> *Are any of the concerns valid against older kernels such as the 4.4.x series 
> or the 3.14.x series?  I ask because several ARM devices use these as their 
> mainline kernels.
> 
> Thanks all!
> 
> 1. https://www.stgraber.org/2014/01/17/lxc-1-0-unprivileged-containers
> 
> 2. https://bugs.archlinux.org/task/36969
> 3. https://bugs.archlinux.org/task/49337
> ___
> lxc-users mailing list
> lxc-users@lists.linuxcontainers.org
> http://lists.linuxcontainers.org/listinfo/lxc-users
___
lxc-users mailing list
lxc-users@lists.linuxcontainers.org
http://lists.linuxcontainers.org/listinfo/lxc-users