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

[Tetsuo Handa]

On 2023/10/02 19:56, Tetsuo Handa wrote:
>> 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.

If "[PATCH v15 01/11] LSM: Identify modules by more than name" does not allow LKM-based
LSMs (which are likely out-of-tree) to have stable LSM ID values, lsm_list_modules()
provided by "[PATCH v15 05/11] LSM: Create lsm_list_modules system call" cannot report
stable string names. And "[PATCH v15 11/11] LSM: selftests for Linux Security Module
syscalls" cannot work on LKM-based LSMs.

Then, how are LKM-based LSMs activated? LKM-based LSMs can use LSM hooks but cannot use
(or show up in) lsm_get_self_attr()/lsm_set_self_attr()/lsm_list_modules() syscalls?
That looks quite strange, for the title of "[PATCH v15 01/11]" is not "LSM: Identify only
built-in and in-tree modules by more than name".

If you think about allowing LKM-based LSMs a bit, you will find that how can the current policy
be compatible. We cannot introduce lsm_get_self_attr()/lsm_set_self_attr()/lsm_list_modules()
syscalls without admitting stable LSM ID values being assigned to any publicly available LSMs.

Simple notification to the LSM community has to be the only requirement for assigning
stable LSM ID values. You should not distinguish in-tree and not-in-tree LSMs regarding
"[PATCH v15 00/11] LSM: Three basic syscalls". Otherwise, the attempt to introduce these
syscalls is a regression that will harm LKM-based LSMs.