[lxc-users] Risk/benefit of enabling user namespaces in the kernel for running unprivileged containers
Fajar A. Nugraha
list at fajar.net
Fri Jan 13 21:56:09 UTC 2017
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>
More information about the lxc-users
mailing list