On Fri, Jan 22, 2016 at 7:02 PM, Eric W. Biederman <ebiederm@xxxxxxxxxxxx> wrote: > Kees Cook <keescook@xxxxxxxxxxxx> writes: > >> There continues to be unexpected side-effects and security exposures >> via CLONE_NEWUSER. For many end-users running distro kernels with >> CONFIG_USER_NS enabled, there is no way to disable this feature when >> desired. As such, this creates a sysctl to restrict CLONE_NEWUSER so >> admins not running containers or Chrome can avoid the risks of this >> feature. > > I don't actually think there do continue to be unexpected side-effects > and security exposures with CLONE_NEWUSER. It takes a while for all of > the fixes to trickle out to distros. At most what I have seen recently > are problems with other kernel interfaces being amplified with user > namespaces. AKA the current mess with devpts, and the unexpected > issues with bind mounts in mount namespaces. > > > So to keep this productive. Please tell me about the threat model > you envision, and how you envision knobs in the kernel being used to > counter those threats. I consider the ability to use CLONE_NEWUSER to acquire CAP_NET_ADMIN over /any/ network namespace and to thus access the network configuration API to be a huge risk. For example, unprivileged users can program iptables. I'll eat my hat if there are no privilege escalations in there. (They can't request module loading, but still.) --Andy -- To unsubscribe from this list: send the line "unsubscribe linux-doc" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
