[PATCH] Do not require attributes for security_inode_init_security.

[Paul Moore]

On Sat, Mar 30, 2024 at 4:14 PM Dr. Greg <greg at enjellic.com> wrote:
>
> It is now perfectly clear that the LSM maintainers don't consider the
> possibility of breaking upstream BPF to be an issue of concern, no
> doubt an important clarification for everyone moving forward.

I've said this before on-list, but I'll repeat it here for those who
might not follow every thread or email.  The BPF LSM is a bit of an
odd case as while there is a very simple structure (framework?)
present in-tree, the actual implementation of the LSM is out-of-tree.
While one could draw some parallels between BPF LSM implementations
and other LSMs with loadable security policies, there is an important
difference in that the conventional LSMs with loadable security
policies separate the security policy from the enforcement engine code
and maintain the enforcement engine code in the upstream Linux kernel.
The BPF LSM maintains the enforcement engine code outside the upstream
Linux kernel and because of that it is impossible for us, the upstream
Linux devs, to do any meaningful analysis of BPF LSM behaviors.

The result of this is that I currently give individual BPF LSMs
largely the same consideration I would give out-of-tree kernel code: I
am not going to go out of my way to block, or otherwise negatively
impact the implementations, but I'm not going to sacrifice the
development of any of the in-tree LSMs, or the LSM layer itself,
solely for the advantage of an out-of-tree implementation.  If you're
really craving an official policy, that's the policy-of-the-moment.

-- 
paul-moore.com