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

[Casey Schaufler]

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

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