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

[Paul Moore]

On Fri, Sep 22, 2023 at 7:25 AM Tetsuo Handa
<penguin-kernel at i-love.sakura.ne.jp> wrote:
> On 2023/09/21 22:58, KP Singh wrote:
> > 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.
> 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...

...

> > 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.
>
> 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.

Despite a previous comment that I was done engaging with Tetsuo on
this topic, I feel it is worth commenting here as there are a number
of people on the To/CC line that have likely not been following the
related discussion threads on the LSM list.

First and foremost I want to reiterate that the LSM community's first
priority are those LSMs which have been accepted and merged into the
upstream Linux kernel.  While I have no intention, or desire, to harm
out-of-tree LSMs, I stand firm that we should not compromise designs
for in-tree LSMs/functionality solely to benefit out-of-tree LSMs.  I
believe this is consistent, or at least compatible, with the general
Linux kernel community's stance on in-tree vs out-of-tree code.

The (relatively) newly proposed LSM syscalls have proven to be a
contentious topic between Tetsuo and the LSM community as a whole; I
won't rehash the arguments here, as they are all available on
lore.kernel.org (simply look for any threads that Tetsuo has been
involved in over the past several months) but we have discussed this
issue at great length and Tetsuo remains the only opposing opinion.
It was my hope that Tetsuo would respect the opinion of the upstream
LSM community, even if he didn't agree with the details.  After all,
this is how we move forward in cases where differing opinions cannot
all be accommodated in the code.

Unfortunately Tetsuo's continued and stubborn refusal to accept the
majority opinion has started to spill into other discussion threads,
disrupting the discussion there and twisting some of the core issues
to better fit his arguments.  Not only is this frustrating, it is
becoming rather disruptive.  My suggestion is to simply follow some
classic Internet advice and "don't feed the trolls".

As we discussed off-list (and in-person!) this week, I am generally
supportive of work that improves performance, but correctness will
always be my priority with maintainability a close second.  We have a
few more pressing issues at the LSM layer which are demanding my time
at the moment, but I do promise to come back to this issue/patchset as
these other high priority issues are resolved.

Thanks for your patience and understanding KP :)

-- 
paul-moore.com