On Sat, Jan 14, 2017 at 4:56 AM, Fajar A. Nugraha <l...@fajar.net> wrote:
> 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 > > 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
_______________________________________________ lxc-users mailing list lxc-users@lists.linuxcontainers.org http://lists.linuxcontainers.org/listinfo/lxc-users