Re: LSM stacking in next for 6.1?

On Thu, Sep 8, 2022 at 11:19 AM Tetsuo Handa <penguin-kernel(a)i-love.sakura.ne.jp&gt; wrote: At least one of those, Landlock, has been merged upstream and is now available in modern released Linux Kernels. As far as the other LSMs are concerned, I don't recall there ever being significant interest among other developers or users to warrant their inclusion upstream. If the authors believe that has changed, or is simply not true, they are always welcome to post their patches again for discussion, review, and potential upstreaming. However, I will caution that it is becoming increasingly difficult for people to find time to review potential new LSMs so it may a while to attract sufficient comments and feedback. As has been discussed before, this isn't so much an issue with the __ro_after_init change, it's really more of an issue of running out-of-tree kernel code on pre-built distribution kernels, with "pre-built" being the most important part. It is my understanding that if the user/developer built their own patched kernel this would not likely be an issue as the out-of-tree LSM could be patched into the kernel source. The problem comes when the user/developer wants to dynamically load their out-of-tree LSM into a pre-built distribution kernel, presumably to preserve a level of distribution support. Unfortunately, to the best of my knowledge, none of the major enterprise Linux distributions will provide support for arbitrary third-party kernel modules (it may work, but if something fails the user is on their own to triage and resolve). Beyond the support issue, there are likely to be other problems as well since the kernel interfaces, including the LSM hooks themselves, are not guaranteed to be stable across kernel releases. I would challenge you to support that claim with data. Granted, we are coming from very different LSM backgrounds, but I find that number very suspect. It has been several years since I last looked, but I believe the latest published Android numbers would give some support to the idea that more than 1% of SELinux based systems are running in enforcing (or permissive) mode. Significantly more. Once again, if you are going to make strong claims such as this, please provide data. I know of several RHEL users that are only able to run SELinux based systems as it is the only LSM which meets their security requirements. I suspect IBM/RH's decision to change CentOS' relationship to RHEL also resulted in a number of users moving to Ubuntu, and that has nothing to do with the LSMs. Every LSM is different, that is partly why it is so interesting as a security framework. Look at Yama, look at AppArmor, look at Smack, look at the BPF LSM ... there is no one security model, and claiming that the LSM focuses on syscalls is misleading. If you had to pick only one concept that the LSM focuses on, I believe it would be providing visibility and access controls for security relevant interactions between entities on the system. Processes opening files, processes executing other processes, processes talking to each other both across the network and on the local system. Some of these things involve syscalls, but as most of us know, making meaningful access control decisions often involves much more than just the syscall. I would caution against confusing the security policy driven access controls provided by many in-tree LSMs with out-of-tree antivirus software. They have different goals, different use cases, and different user groups (markets). I think that is about the nicest thing I can think to say about those antivirus products ;) -- paul-moore.com