[PATCH 04/10] CaitSith: Add header file.

[Kees Cook]

On November 9, 2022 3:57:06 PM PST, Tetsuo Handa <penguin-kernel at I-love.SAKURA.ne.jp> wrote:
>On 2022/11/09 23:48, Paul Moore wrote:
>>                                             If there is a significant
>> change, e.g. the overall kernel policy towards out-of-tree code, we
>> can reconsider this policy but as of right now only upstream LSMs will
>> have LSM ID tokens assigned to them; in-development LSMs are free to
>> temporarily assign themselves an ID token (which may change when the
>> LSM is merged upstream), and out-of-tree LSMs are free to do whatever
>> they like with respect to their code, just as they do now.
>
>If in-development LSMs and out-of-tree LSMs cannot get a stable ID token,
>developers cannot write and publish userspace tools which make use of ID
>token. If ID collision happens by use of temporarily ID token, this token
>is no longer an identifier. That is a pointless and needless constraint
>for getting LSM modules created / tested / used.

You have to let this go. You aren't hearing us: this ID reservation process is not a problem for anyone but you. It is the same for all the syscalls that get added, and all the prctls, etc etc. This isn't a problem for userspace tools using those, and there won't be a problem here either.

We will not support out of tree code, so needing ID stability for out-of-tree LSMs isn't a valid argument.

Additionally, not having an LSM built into a distro kernel is a distro kernel problem. Open a bug with them and get it fixed. E.g. Ubuntu has no problem with multiple LSMs:

$ grep 'CONFIG_SECURITY_[^_]*[ =]' /boot/config-$(
uname -r)
...
CONFIG_SECURITY_SELINUX=y
CONFIG_SECURITY_SMACK=y
CONFIG_SECURITY_TOMOYO=y
CONFIG_SECURITY_APPARMOR=y
# CONFIG_SECURITY_LOADPIN is not set
CONFIG_SECURITY_YAMA=y
CONFIG_SECURITY_SAFESETID=y
CONFIG_SECURITY_LANDLOCK=y

And they just leave the "exclusive"s disabled at runtime:
CONFIG_LSM="landlock,lockdown,yama,integrity,apparmor"

-Kees


-- 
Kees Cook