[RFC PATCH 1/2] LSM: Allow dynamically appendable LSM modules.

[Tetsuo Handa]

On 2023/10/04 8:39, Paul Moore wrote:
> As far as I can tell this RFC isn't really about dynamically loadable
> LSMs, it's about blocking the LSM syscall work, specifically the LSM
> ID tokens.  As I've said many times before, the LSM ID concept is
> moving forward and if you can't respect that decision, at least stop
> wasting our time.

This RFC is mainly about how do we plan to allow LKM-based LSMs.
Two proposals (LSM ID and elimination of linked list) might damage
LKM-based LSMs.

Regarding LSM ID, I'm asserting that assigning stable LSM ID to every LSM
is the *better* usage, for users can find whatever LSMs like CVE database
and developers can avoid possible collisions in the LSM infrastructure and
developers can avoid writing obvious duplicates (like you want to reject
proposals that are sufficiently "close"). If some ID were assigned to
implementations like https://github.com/linux-lock/bpflock , users can find
implementations that fit their needs more easily...

BTW, is bpflock considered as an LSM module entity that should be recognized
(i.e. assigned a stable LSM ID) so that the LSM syscalls can return "bpflock" ?
If users want to know which hook caused an access request to be rejected,
having the granularity of "bpf" might not be sufficient...