On Thu, Jan 28, 2016 at 9:41 AM, Eric W. Biederman <ebiederm@xxxxxxxxxxxx> wrote: > Kees Cook <keescook@xxxxxxxxxxxx> writes: > >> There continue to be unexpected security exposures when users have access >> to CLONE_NEWUSER. > > So how does this sucessfully address that issue? I've explained this several times. It disables new user namespaces. I've asked earlier but got no answer: is revocation a requirement for this feature? >> For admins of systems that do not use user namespaces >> and are running distro kernels with CONFIG_USER_NS enabled, there is >> no way to disable CLONE_NEWUSER. This provides a way for sysadmins to >> disable the feature to reduce their attack surface without needing to >> rebuild their kernels. >> >> This is inspired by a similar restriction in Grsecurity, but adds >> a sysctl. >> > > I have already nacked this patch. Thank you for removing the broken > capability in sysctl check. But this does not address any of the other > issues I have raised. I also asked about implementation directions but got no reply: do you want this as an rlimit, or something else? > Nacked-by: "Eric W. Biederman" <ebiederm@xxxxxxxxxxxx> > > Further as far as I can tell this is just about a witch hunt. Isn't > that what you call a campaign against something when the complaining > party does not understand something persecutes it and does not bother to > try and understand? > > I have already told you what kind of direction would be acceptable. I > gave concrete suggests and here you are wasting our time with this patch > again. I wanted to have a "clean" version of the sysctl patch and figured I'd share it since it was the implementation that Andy and others had showed interest in, even if it won't be the final version of this feature. -Kees -- Kees Cook Chrome OS & Brillo Security -- 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
