On Mon, Aug 8, 2022 at 2:56 PM Eric W. Biederman ebiederm@xmission.com wrote:
Paul Moore paul@paul-moore.com writes:
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.
I did provide constructive feedback. My feedback to his problem was to address the real problem of bugs in the kernel.
We've heard from several people who have use cases which require adding LSM-level access controls and observability to user namespace creation. This is the problem we are trying to solve here; if you do not like the approach proposed in this patchset please suggest another implementation that allows LSMs visibility into user namespace creation.