Casey Schaufler casey@schaufler-ca.com writes:
Smack has no interest in using the proposed hook because user namespaces are neither subjects nor objects. They are collections of DAC and/or privilege configuration alternatives. Or something like that. From the viewpoint of a security module that only implements old fashioned MAC there is no value in constraining user namespaces.
The goal is to simply enable things that become safe when you don't have to worry about confusing setuid executables.
SELinux, on the other hand, seeks to be comprehensive well beyond controlling accesses between subjects and objects. Asking the question "should there be a control on this operation?" seems sufficient to justify adding the control to SELinux policy. This is characteristic of "Fine Grain" control.
I see that from a theoretical standpoint. On the flip side I prefer arguments grounded in something more than what an abstract framework could appreciate. We are so far from any theoretical purity in the linux kernel that I can't see theoretical purity being enough to justify a decision like this.
So I'm of two minds on this. I don't need the hook, but I also understand why SELinux and BPF want it. I don't necessarily agree with their logic, but it is consistent with existing behavior. Any system that uses either of those security modules needs to be ready for unexpected denials based on any potential security concern. Keeping namespaces completely orthogonal to LSM seems doomed to failure eventually.
I can cross that bridge when there is a healthy conversation about such a change.
Too often I get "ouch! Creating a user namespace was used as the easiest way to exploit a security bug. Let's solve the issue by denying user namespaces." Which leads to half thought out policies made out of fear.
Which is where I think this conversation started. I haven't seen it make it's way to any healthy reasons to deny user namespaces yet.
Eric