On Fri, Jan 13, 2017 at 08:52:14PM +0000, John wrote: > > > > > ----- Original Message ----- > > From: Serge E. Hallyn <se...@hallyn.com> > > To: LXC users mailing-list <lxc-users@lists.linuxcontainers.org> > > Sent: Friday, January 13, 2017 11:20 AM > > Subject: Re: [lxc-users] Risk/benefit of enabling user namespaces in the > > kernel for running unprivileged containers > > >> I'm unclear about several points: > >> *Is it true that enabling CONFIG_USER_NS makes LXCs safer but at the cost > > of decreasing security on the host? > > > > "basically" > > > > "decreasing security on the host" implies there are known > > vulnerabilities or > > shortcomings which you are enabling as a tradeoff. That's not the case. > > Rather, > > there are so many interactions between types of resources that we keep > > running > > into new ways in which unanticipated interactions can lead to > > vulnerabilities > > when unprivileged users gain the ability to create new namespaces. > > > > Some of the 'vulnerabilities' are pretty arguable, for instance the > > ability > > for an unprivileged user to escape a negative acl by dropping a group, or to > > see an overmounted file in a new namespace. But others are very serious. > > > > When that will settle down, noone really knows. >
Sorry, this got lost in my backlog. Been bad about inbox 0. > 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? It dpeends. The ACL one I mentioned above is only relevant for users who have local (non-container) accounts, since the whole point is that they get around an access restriction imposed on their local user. One thing user namespaces do is allow root in a user namespace, which we call untrusted, to run kernel code which previously was guarded so that only the real trusted root could ever run it. The classic example of this is superblock readers which run when you mount a filesystem to parse its metadata. This in particular is still guarded because it's so unsafe, but there are others. (Just look for any code inside a 'if ns_capable()' check). If such code has a bug, then root in a container can exercise that bug. > 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. It can be the container itself - the question is who will exploit it. Do you trust your local users? Do you allow containers to run services that are open to the world? For instance if a container exports a web app or a mysql service, then an attacker might exploit a mysql bug to get access as the mysql user in the container, then run one kernel exploit to become container, root, then exploit another kernel bug to do something which only the host root should be able to do. But I think (I've not looked over the list of known CVEs - i really need to) most of the bugs have been more of the sort where a local non-root user does something in a new user namespace, which he can create with absolutely no privilege. -serge _______________________________________________ lxc-users mailing list lxc-users@lists.linuxcontainers.org http://lists.linuxcontainers.org/listinfo/lxc-users
