On Sat, Sep 23, 2023 at 8:57 AM Tetsuo Handa <penguin-kernel@xxxxxxxxxxxxxxxxxxx> wrote: > > 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. > You are trying to use an unexported symbol from the module with lots of hackery to write to be supported and bring it up in a discussion? Good luck! Regardless, if what you are doing really works after https://lore.kernel.org/all/20200107133154.588958-1-omosnace@xxxxxxxxxx, then we need to fix this as the security_hook_heads should be immutable after boot. I tried a build where the symbols are exported and sure enough the module is unable to write to it. So, either your kernel has the old CONFIG_SECURITY_HOOKS_WRITABLE, or it should ideally fail with something like: [ 23.990387] kernel tried to execute NX-protected page - exploit attempt? (uid: 0) [ 23.996796] BUG: unable to handle page fault for address: ffffffff83adf270 [ 23.997433] #PF: supervisor instruction fetch in kernel mode [ 23.997936] #PF: error_code(0x0011) - permissions violation [ 23.998416] PGD 3247067 P4D 3247067 PUD 3248063 PMD 100b9e063 PTE 8000000003adf163 [ 23.999069] Oops: 0011 [#1] PREEMPT SMP NOPTI [ 23.999445] CPU: 0 PID: 302 Comm: insmod Tainted: G O 6.6.0-rc2-next-20230921-dirty #13 [ 24.000230] Hardware name: QEMU Standard PC (Q35 + ICH9, 2009), BIOS 1.16.2-debian-1.16.2-1 04/01/2014 [ 24.001024] RIP: 0010:security_add_hooks+0x0/0xa0 If this is not happening, then it's a bug and you chose to report it. > > > >>> > >>> 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". This does not belong here, please stop cross posting stuff. > > 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. Please stop making generic statements, either be explicit about your understanding of the limitations or don't claim them without evidence. - KP > > 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. >
