On Mon, Aug 1, 2022 at 10:56 PM Eric W. Biederman ebiederm@xmission.com wrote:
Frederick Lawler fred@cloudflare.com writes:
While creating a LSM BPF MAC policy to block user namespace creation, we used the LSM cred_prepare hook because that is the closest hook to prevent a call to create_user_ns().
Re-nack for all of the same reasons. AKA This can only break the users of the user namespace.
Nacked-by: "Eric W. Biederman" ebiederm@xmission.com
You aren't fixing what your problem you are papering over it by denying access to the user namespace.
Nack Nack Nack.
Stop.
Go back to the drawing board.
Do not pass go.
Do not collect $200.
If you want us to take your comments seriously Eric, you need to provide the list with some constructive feedback that would allow Frederick to move forward with a solution to the use case that has been proposed. You response above may be many things, but it is certainly not that.
We've heard from different users now that there are very real use cases for this LSM hook. I understand you are concerned about adding additional controls to user namespaces, but these are controls requested by real users, and the controls being requested (LSM hooks, with BPF and SELinux implementations) are configurable by the *users* at *runtime*. This patchset does not force additional restrictions on user namespaces, it provides a mechanism that *users* can leverage to add additional granularity to the access controls surrounding user namespaces.
Eric, if you have a different approach in mind to adding a LSM hook to user namespace creation I think we would all very much like to hear about it. However, if you do not have any suggestions along those lines, and simply want to NACK any effort to add a LSM hook to user namespace creation, I think we all understand your point of view and respectfully disagree. Barring any new approaches or suggestions, I think Frederick's patches look reasonable and I still plan on merging them into the LSM next branch when the merge window closes.