On Sat, Jan 14, 2017 at 09:39:10AM +0700, Fajar A. Nugraha wrote: > 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.
Indeed in general the container workloads will be protected by extra layers. That's not necessarily where the more serious concern comes in though. The concern is about the fact that unprivileged users on the host can create a new user namespace without those extra layers, and exploit the complications. The new sysctl to disable unprivileged creation of user namespaces is inteded to help with that, as well as, when an 0-day has been found, to temporarily disable the attack vector. Of course that doesn't help if a user creates a new userns and leaves it sitting until a new 0-day has been found, then exploits that from his pre-existing userns. So there are two "scary" scenarious. One is where a web service in an unprivileged container is running a dangerous workload on behalf of an attacker. This is scary because anyone can attack, but is somewhat mitigated by defense in depth. The other is where an unprivileged user on localhost is attacking. That's scary because he can completely avoid the defense in depth, unless you're running a reasonably secured host to begin with. That would mean selinux in this case, because the apparmor model is very explicitly about confining target network-facing services, not local users. On the other hand, you have to not trust your local users, if such exist, for this to become an issues. (Of course, as I like to remind people, most any system, i.e. a "single-user" android phone or amazon instance, is one attack away from becoming a multi-tenant system). -serge _______________________________________________ lxc-users mailing list lxc-users@lists.linuxcontainers.org http://lists.linuxcontainers.org/listinfo/lxc-users
