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