>> The admin of such a machine could have disabled userns months earlier >> and limited the scope of the attack. > > Of course for the paranoid there is already a mechanism to do this. > /sbin/chroot. > > No new user namespaces are allowed to be created inside of a chroot. Another alternative is to create a custom kernel module which will disable the user namespace (by limiting to privileged users only, or disabling it altogether). IMO people tend to use distro kernels for convenience, and a suggestion of creating a chroot dir for every service exposed to users, or building a custom kernel module is an advice that not many sysadmins using distro kernels would take, even if they have concerns about the the increased attack surface enabled by CLONE_NEWUSER. Also, I don't think the willingness to disable the feature or limit it to the already privileged users will be something that only truly paranoid sysadmins/users would have. We've seen a fair amount of privilege escalation / DoS bugs that this kernel feature enabled in the recent 18 months or so, and they still seem to be found on a somewhat regular basis. Therefore this discussion and its outcome might be of interest to less paranoid folk as well. I agree with Kees that the "knob" will be mostly used by admins of web-servers (and similar services) as a protection against privilege escalation after getting low-priv code execution on the system. Therefore a sysctl enabled from /etc/sysctl.conf should work well here, even if it's set to the permissive mode by default at boot. -- 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
