On Fri, Oct 28, 2022 at 10:58:30PM +0900, Tetsuo Handa wrote:
There was also:
LoadPin ( 2016/04/20
https://lore.kernel.org/lkml/1461192388-13900-1-git-send-email-keescook@c... )
SafeSetID ( 2018/10/31
https://lore.kernel.org/linux-security-module/20181031152846.234791-1-mor...
)
BPF ( 2019/09/10
https://lore.kernel.org/linux-security-module/20190910115527.5235-1-kpsin...
)
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