On Fri, Oct 28, 2022 at 10:58:30PM +0900, Tetsuo Handa wrote: > Do you remember that 10 modules were proposed > > SimpleFlow ( 2016/04/21 https://lwn.net/Articles/684825/ ) > HardChroot ( 2016/07/29 https://lwn.net/Articles/695984/ ) > Checmate ( 2016/08/04 https://lwn.net/Articles/696344/ ) > LandLock ( 2016/08/25 https://lwn.net/Articles/698226/ ) > PTAGS ( 2016/09/29 https://lwn.net/Articles/702639/ ) > CaitSith ( 2016/10/21 https://lwn.net/Articles/704262/ ) > SafeName ( 2016/05/03 https://lwn.net/Articles/686021/ ) > WhiteEgret ( 2017/05/30 https://lwn.net/Articles/724192/ ) > shebang ( 2017/06/09 https://lwn.net/Articles/725285/ ) > S.A.R.A. ( 2017/06/13 https://lwn.net/Articles/725230/ ) There was also: LoadPin ( 2016/04/20 https://lore.kernel.org/lkml/1461192388-13900-1-git-send-email-keescook@xxxxxxxxxxxx/ ) SafeSetID ( 2018/10/31 https://lore.kernel.org/linux-security-module/20181031152846.234791-1-mortonm@xxxxxxxxxxxx/ ) BPF ( 2019/09/10 https://lore.kernel.org/linux-security-module/20190910115527.5235-1-kpsingh@xxxxxxxxxxxx/ ) So, 13 LSM proposed, 4 landed: roughly 30%, which is on par[1] with regular kernel development. > I consider /sbin/insmod-able LSM modules as a compromise/remedy for LSM modules > which could not get merged upstream or supported by distributors, for patching and > rebuilding the whole kernel in order to use not-yet-upstreamed and/or not-builtin > LSMs is already a lot of barrier for users. But requiring a permanent integer in > order to use a LSM module is a denial of even patching and rebuilding the whole > kernel. That's why I hate this change. But the upstream kernel _does not support APIs for out-of-tree code_. To that point, security_add_hooks() is _not exported_, so it is already not possible to create a modular LSM without patching the kernel source. > I can't understand why assigning a permanent integer identifier is mandatory. Plenty of other APIs use numeric identifiers: syscalls, prctl, etc. This doesn't block them from being upstreamed. -Kees [1] https://ieeexplore.ieee.org/abstract/document/6624016 -- Kees Cook
