Separate CAP_* for CLONE_NEWUSER?

[emilazy]

Currently, CLONE_NEWUSER is gated on CAP_SYS_ADMIN when kernel.unprivileged_userns_clone = 0; I understand why (any vulnerability in user namespaces, which is what the setting exists to guard against, would lead to immediate escalation to admin anyway), but it means that there's no easy way to narrow down a system's overall attack surface by allowing a specific few processes that use the functionality to use CLONE_NEWUSER without implicitly running all their code with CAP_SYS_ADMIN or allowing arbitrary unprivileged processes to use userns. After writing NixOS/nixpkgs#84522 (comment) I figured I'd open this to at least see if there's any appetite for this.

I guess this is something that could be accomplished via SELinux, and would be out of scope if so?

[Bernhard40]

Adding new capability needs userspace to support it which is basically undoable when mainline kernel doesn't have this new capability.

[anthraxx]

I don't think this is a feasible approach for this project to fundamentally deviate capabilities from vanilla as there is tons of downstream cap stuff that needs to be aware of it as well. I agree that if there is any separation desired in terms of capabilities this should happen in the vanilla kernel if possible. However I hardly doubt anything like that will be in cooperated as there has been quite some hysteria around userns especially around this switch which is nowadays relatively often being adopted as an addition.
The mostly viable approach for now would be to have a tiny helper that has elevated privileges and use that to setup your runtime space without the need of having to run the whole application with elevated privileges.

[emilazy]

Makes sense; the userland considerations and potential for clashes make this pretty much untenable.