Re: [PATCH] Do not require attributes for security_inode_init_security.
From: Paul Moore <paul@paul-moore.com>
Date: 2024-03-31 15:03:10
On Sat, Mar 30, 2024 at 4:14 PM Dr. Greg [off-list ref] 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