On 2023/09/22 23:45, KP Singh wrote: >> I'm using LKM-based LSM with any version between 2.6.0 and 6.6-rc2, without patching >> __ro_after_init out. We can load LKM-based LSMs, without patching the original kernel. > > Then __ro_after_init is broken in your tree and you are missing some patches. This fact applies to vanilla upstream kernel tree; __ro_after_init is not broken and some patches are not missing. See https://akari.osdn.jp/1.0/chapter-3.html.en for details. >>> >>> The performance benefits here outweigh the need for a completely >>> unsupported use case. >> >> LKM-based LSMs are not officially supported since 2.6.24. But people need LKM-based LSMs. >> It is very sad that the LSM community is trying to lock out out of tree LSMs >> ( https://lkml.kernel.org/r/ec37cd2f-24ee-3273-c253-58d480569117@xxxxxxxxxxxxxxxxxxx ). >> The LSM interface is a common property for *all* Linux users. > > Again, I don't understand how this locks out out-of-tree LSMs. One can > go and patch static calls the same way one hacked around by directly > adding stuff to the security_hook_heads. I am not going to suggest any > hacks here but there are pretty obvious solutions out there.; The change that locks out out-of-tree LSMs (regardless of whether that LSM is LKM-based LSM or not) is a series including "[PATCH v15 01/11] LSM: Identify modules by more than name". I was not pushing LKM-based LSM because the LSM community wanted to make it possible to enable arbitrary combinations (e.g. enabling selinux and smack at the same time) before making it possible to use LKM-based LSMs. According to https://marc.info/?l=linux-security-module&m=123232076329805 (Jan 2009), Casey said that "SELinux and Smack should never be stacked in the same kernel.". I'm personally wondering how many users will enable selinux and smack at the same time. But in that post, Casey also said "You could revive the notion of loadable modules while you're at it." while implementing LSM Multiplexer LSM. According to https://marc.info/?l=linux-security-module&m=133055410107878 (Feb 2012), Casey said that support for multiple concurrent LSMs should be able to handle loadable/unloadable LSMs. The reason for removing unload support was that no in-tree users needed it, and out of tree use-cases are generally not supported in mainline. That is, when the LSM interface became static, the LSM community was not seeing the reality. I don't think that rmmod support for LKM-based LSMs is needed, but I believe that insmod support for LKM-based LSMs is needed. According to https://lkml.kernel.org/r/50ABE354.1040407@xxxxxxxxxxxxxxxx (Nov 2012), Casey said that reintroducing LSMs as loadable modules is a work for another day and a separate battle to fight. These postings (just picked up from LSM mailing list archives matching keyword "loadable" and sent from Casey) indicate that the LSM community was not making changes that forever makes LKM-based LSMs impossible. Finally, pasting Casey's message (Feb 2016) here (because the archive did not find this post): From: Casey Schaufler <casey@xxxxxxxxxxxxxxxx> Subject: Re: LSM as a kernel module Date: Mon, 22 Feb 2016 10:17:26 -0800 Message-ID: <56CB50B6.6060702@xxxxxxxxxxxxxxxx> To: Roman Kubiak <r.kubiak@xxxxxxxxxxx>, linux-security-module@xxxxxxxxxxxxxxx On 2/22/2016 5:37 AM, Roman Kubiak wrote: > I just wanted to make sure that it's not possible and is not planned in the future > to have LSM modules loaded as .ko kernel modules. Is that true for now and the far/near future ? > > best regards Tetsuo Handa is holding out hope for loadable security modules*. The work I've been doing on module stacking does not include support for loadable modules, but I've committed to not making it impossible. There has never really been a major issue with loading a security module, although there are a host of minor ones. The big problem is unloading the module and cleaning up properly. Near term I believe that you can count on not having to worry about dynamically loadable security modules. At some point in the future we may have an important use case, but I don't see that until before some time in the 20s. So now I'm curious. What are you up to that would be spoiled by loadable security modules? --- * The original name for the infrastructure was indeed "Loadable Security Modules". The memory management and security policy implications resulted in steadily diminishing support for any sort of dynamic configuration. It wasn't long before "Loadable" became "Linux". But while I was waiting for "make it possible to enable arbitrary combinations" change, the LSM community started making changes (such as defining the maximum number of "slots" or "static calls" based on all LSMs are built into vmlinux) that violate Casey's promise. As a reminder to tell that I still want to make LKM-based LSM officially supported again, I'm responding to changes (like this patch) that are based on "any LSM must be built into vmlinux". Please be careful not to make changes that forever make LKM-based LSMs impossible. > > My recommendation would be to use BPF LSM for any custom MAC policy > logic. That's the whole goal of the BPF LSM is to safely enable these > use cases without relying on LSM internals and hacks. I'm fine if you can reimplement TOMOYO (or AKARI or CaitSith) using BPF LSM. Since BPF has many limitations, not every custom MAC policy can be implemented using BPF. The need to insmod LKM-based LSMs will remain because the LSM community will not accept whatever LSMs (that are publicly available) and the Linux distributors will not build whatever LSMs (that are publicly available) into their vmlinux. But "LSM: Identify modules by more than name" is the worst change because that change locks out any publicly available out of tree LSMs, far away from allowing LKM-based LSMs.
