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?


"decreasing security on the host" implies there are known vulnerabilities or
shortcomings which you are enabling as a tradeoff.  That's not the case.  
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

Reply via email to