> > I just merged this into the lsm/next tree, thanks for seeing this > through Frederick, and thank you to everyone who took the time to > review the patches and add their tags. > > git://git.kernel.org/pub/scm/linux/kernel/git/pcmoore/lsm.git next Paul, Frederick I repeat my NACK, in part because I am being ignored and in part because the hook does not make technical sense. Linus I want you to know that this has been put in the lsm tree against my explicit and clear objections. My request to talk about the actual problems that are being address has been completely ignored. I have been a bit slow in dealing with this conversation because I am very much sick and not on top of my game, but that is no excuse to steam roll over me, instead of addressing my concerns. This is an irresponsible way of adding an access control to user namespace creation. This is a linux-api and manpages level kind of change, as this is a semantic change visible to userspace. Instead that concern has been brushed off as different return code to userspace. For observably this is a terrible LSM interface because there is no pair with user namespace destruction, nor is their any ability for the LSM to allocate any state to track the user namespace. As there is no patch actually calling audit or anything else observably does not appear to be a driving factor of this new interface. The common scenarios I am aware of for using the user namespace are: - Creating a container. - Using the user namespace to sandbox your application like chrome does. - Running an exploit. Returning an error code in the first 2 scenarios will create a userspace regression as either userspace will run less securely or it won't work at all. Returning an error code in the third scenario when someone is trying to exploit your machine is equally foolish as you are giving the exploit the chance to continue running. The application should be killed instead. Further adding a random failure mode to user namespace creation if it is used at all will just encourage userspace to use a setuid application to perform the namespace creation instead. Creating a less secure system overall. If the concern is to reduce the attack surface everything this proposed hook can do is already possible with the security_capable security hook. So Paul, Frederick please drop this. I can't see what this new hook is good for except creating regressions in existing userspace code. I am not willing to support such a hook in code that I maintain. Eric
