[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 <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.

-- 
Fajar
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxcontainers.org/pipermail/lxc-users/attachments/20170114/cd7bd823/attachment.html>