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

[KP Singh]

On Fri, Sep 22, 2023 at 4:57 PM Paul Moore <paul at paul-moore.com> wrote:
>
> 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 :)

Thank you for the context Paul, this explains a lot!


>
> --
> paul-moore.com