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