On Sat, Sep 23, 2023 at 8:57 AM Tetsuo Handa
[off-list ref] wrote:

On 2023/09/22 23:45, KP Singh wrote:

quoted

quoted

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@redhat.com (local),
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.

quoted

quoted

quoted

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@I-love.SAKURA.ne.jp ).
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@schaufler-ca.com (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 [off-list ref]
  Subject: Re: LSM as a kernel module
  Date: Mon, 22 Feb 2016 10:17:26 -0800
  Message-ID: [off-list ref]
  To: Roman Kubiak [off-list ref], linux-security-module@vger.kernel.org

  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.

quoted

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.