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

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.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxcontainers.org/pipermail/lxc-users/attachments/20170114/eb8812f1/attachment.html>