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

[KP Singh]

On Mon, Oct 2, 2023 at 12:56 PM Tetsuo Handa
<penguin-kernel at i-love.sakura.ne.jp> wrote:
>
> On 2023/10/02 0:00, Casey Schaufler wrote:
> > On 10/1/2023 3:51 AM, Tetsuo Handa wrote:
> >> On 2023/09/25 20:22, KP Singh wrote:
> >>>> It is Casey's commitment that the LSM infrastructure will not forbid LKM-based LSMs.
> >>>> We will start allowing LKM-based LSMs. But it is not clear how we can make it possible to
> >>>> allow LKM-based LSMs.
> >>> I think this needs to be discussed if and when we allow LKM based LSMs.
> >> It is *now* (i.e. before your proposal is accepted) that we need to discuss.
> >>
> >>> One needs to know MAX_LSM_COUNT at compile time (not via kernel
> >>> command line), I really suggest you try out your suggestions before
> >>> posting them. I had explained this to you earlier, you still chose to
> >>> ignore and keep suggesting stuff that does not work.
> >> Your proposal needs to know MAX_LSM_COUNT at compile time, that's why
> >> we need to discuss now.
> >>
> >>> We will see when this happens. I don't think it's a difficult problem
> >>> and there are many ways to implement this:
> >>>
> >>> * Add a new slot(s) for modular LSMs (One can add up to N fast modular LSMs)
> >>> * Fallback to a linked list for modular LSMs, that's not a complexity.
> >>> There are serious performance gains and I think it's a fair trade-off.
> >>> This isn't even complex.
> >> That won't help at all.
> >
> > This is exactly the solution I have been contemplating since this
> > discussion began. It will address the bulk of the issue. I'm almost
> > mad/crazy enough to produce the patch to demonstrate it. Almost.
>
> Yes, please show us one. I'm fine if the mechanism which allows LKM-based LSMs
> cannot be disabled via the kernel configuration options.
>
> I really want a commitment that none of the LSM community objects revival of
> LKM-based LSMs. I'm worrying that some of the LSM community objects revival of
> LKM-based LSMs because adding extra slots and/or linked list is e.g. an overhead,
> increases attack surface etc.
>
> Let's consider the Microsoft Windows operating system. Many security vendors are
> offering security software which can run without recompiling the Windows OS.
>
> But what about Linux? Security vendors cannot trivially add a security mechanism
> because LKM-based LSMs are not supported since 2.6.24. As a result, some chose
> hijacking LSM hooks, and others chose overwriting system call tables.
>
> The Linux kernel is there for providing what the user needs. What about the LSM
> infrastructure? The LSM infrastructure is too much evolving towards in-tree and
> built-in security mechanisms.
>
> The consequence of such evolving will be "Limited Security Modes" where users cannot
> use what they need. New ideas cannot be easily tried if rebuild of vmlinux is
> inevitable, which will also prevent a breath of fresh ideas from reaching the LSM
> community.
>
> Never "discussed *if* we allow LKM based LSMs", for the LSM community cannot
> afford accepting whatever LSMs and the Linux distributors cannot afford enabling
> whatever LSMs.
>
> I'm not speaking for the security vendors. I'm speaking from the point of view of
> minority/out-of-tree users.
>
> > There are still a bunch of details (e.g. shared blobs) that it doesn't
> > address. On the other hand, your memory management magic doesn't
> > address those issues either.
>
> Security is always trial-and-error. Just give all Linux users chances to continue
> trial-and-error. You don't need to forbid LKM-based LSMs just because blob management
> is not addressed. Please open the LSM infrastructure to anyone.

It already is, the community is already using BPF LSM.

e.g. https://github.com/linux-lock/bpflock

>