[PATCH v3 2/5] security: Count the LSMs enabled at compile time

[KP Singh]

On Fri, Sep 22, 2023 at 1:25 PM Tetsuo Handa
<penguin-kernel at i-love.sakura.ne.jp> wrote:
>
> On 2023/09/21 22:58, KP Singh wrote:
> > On Thu, Sep 21, 2023 at 3:21 PM Tetsuo Handa
> > <penguin-kernel at i-love.sakura.ne.jp> wrote:
> >>
> >> On 2023/09/19 6:24, KP Singh wrote:
> >>> These macros are a clever trick to determine a count of the number of
> >>> LSMs that are enabled in the config to ascertain the maximum number of
> >>> static calls that need to be configured per LSM hook.
> >>
> >> As a LKM-based LSM user, indirect function calls using a linked list have
> >> an advantage which this series kills. There always is a situation where a
> >
> >
> >> LSM cannot be built into vmlinux (and hence has to be loaded as a LKM-based
> >> LSM) due to distributor's support policy. Therefore, honestly speaking,
> >> I don't want LSM infrastructure to define the maximum number of "slots" or
> >> "static calls"...
> >>
> >
> > Yeah, LSMs are not meant to be used from a kernel module. The data
> > structure is actually __ro_after_init. So, I am not even sure how you
> > are using it in kernel modules (unless you are patching this out).
> > And, if you are really patching stuff to get your out of tree LSMs to
> > work, then you might as well add your "custom" LSM config here or just
> > override this count.
>
> 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.

> And it seems to me that several proprietary security products for Linux are using
> this trick, for LSMs for such products cannot be built into distributor's kernels...
>
> ----------
> [    0.000000] Command line: BOOT_IMAGE=/boot/vmlinuz-6.6.0-rc2+ root=/dev/sda1 ro vconsole.keymap=jp106 vconsole.font=latarcyrheb-sun16 security=none sysrq_always_enabled console=ttyS0,115200n8 console=tty0 LANG=en_US.UTF-8 init=/sbin/akari-init
> (...snipped...)
> [  147.238458] AKARI: 1.0.48   2023/05/27
> [  147.244867] Access Keeping And Regulating Instrument registered.
> [  147.261232] Calling /sbin/ccs-init to load policy. Please wait.
> 239 domains. 11807 ACL entries.
> 1938 KB used by policy.
> [  147.768694] CCSecurity: 1.8.9   2021/04/01
> [  147.768740] Mandatory Access Control activated.
> ----------
>
> >
> > 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.;

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.

- KP

>
> I'm not objecting the performance benefits by replacing with static calls.
> I'm not happy that the LSM community ignores the Torvald's comment at https://lkml.org/lkml/2007/10/1/192
> and does not listen to minority's voices.
>