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

[Tetsuo Handa]

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. You became so blind because what you want to use (i.e.
SELinux and BPF) are already supported by Linux distributors. The reason I'm
insisting on supporting LKM-based LSMs is that Linux distributors cannot afford
supporting minor LSMs.

Dave Chinner said

  Downstream distros support all sorts of out of tree filesystems loaded
  via kernel modules

at https://lkml.kernel.org/r/ZQo94mCzV7hOrVkh@dread.disaster.area , and e.g.
antivirus software vendors use out of tree filesystems loaded via kernel
modules (because neither the upstream kernel community nor the Linux distributors
can afford supporting out of tree filesystems used by antivirus software vendors).

If Linux distributors decide "we don't allow loading out of tree filesystems
via kernel modules because we can't support", that's the end of the world for
such filesystems.

What I'm saying is nothing but s/filesystem/LSM/g .
If Linux distributors decide "we don't allow loading out of tree LSMs
via kernel modules because we can't support", that's the end of the world for
LKM-based LSMs.

The mechanism which makes LKM-based LSMs possible must not be disabled by
the person/organization who builds the vmlinux.

You might still say that "You can build your vmlinux and distribute it", but
that is also impossible in practice. Some device drivers are meant to be loaded
for Linux distribution's prebuilt kernels. Also, debuginfo package is needed for
analyzing vmcore. Building vmlinux and distributing it is not practical without
becoming a well-known Linux distributors enough to get out-of-tree device drivers
being prebuilt (such as Red Hat).

Again, you are so blind.

> Now, this patch and the patch that makes security_hook_heads
> __ro_after_init by removing CONFIG_SECURITY_HOOKS_WRITABLE breaks your
> hack.

Like I demonstrated at https://lkml.kernel.org/r/cc8e16bb-5083-01da-4a77-d251a76dc8ff@I-love.SAKURA.ne.jp ,
removing CONFIG_SECURITY_HOOKS_WRITABLE does not break my hack.