<div dir="ltr"><div class="gmail_extra"><div class="gmail_quote">On Sat, Jan 14, 2017 at 4:56 AM, Fajar A. Nugraha <span dir="ltr"><<a href="mailto:list@fajar.net" target="_blank">list@fajar.net</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div dir="ltr"><div class="gmail_extra"><div class="gmail_quote"><span class="gmail-">On Sat, Jan 14, 2017 at 3:52 AM, John <span dir="ltr"><<a href="mailto:da_audiophile@yahoo.com" target="_blank">da_audiophile@yahoo.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><span class="gmail-m_5927724586009090478gmail-"><br>
</span>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.<br>
<div class="gmail-m_5927724586009090478gmail-HOEnZb"><div class="gmail-m_5927724586009090478gmail-h5"></div></div></blockquote><div><br></div></span><div>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:</div><div><br></div><div>- "classic" mount/pid/network/uts namespace, used by all container implementation</div><div>- kernel security module (lxd in ubuntu enforce apparmor by default, while openshift in redhat enforce selinux)</div><div>- 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)</div><div>- other things I might forgot, like seccomp and linux capabilities</div><div><br></div></div></div></div></blockquote><div><br></div><div><br></div><div>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).</div><div><br></div><div>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.</div><div><br></div><div>-- </div><div>Fajar</div></div></div></div>