LSM stacking in next for 6.1?

[Kees Cook]

On October 30, 2022 7:02:52 AM PDT, Tetsuo Handa <penguin-kernel at I-love.SAKURA.ne.jp> wrote:
>Casey's patchset is trying to provide LSM ID Repository for userspace programs.
>But an LSM ID value cannot be assigned to that LSM unless that module is
>available in the upstream kernel. This means that, developers are not allowed
>to develop a new LSM module even with the intention to become available in the
>upstream kernel, for there always is a risk of LSM ID collision which the LSM ID
>Repository should have avoided from the beginning. Also, this means that, unlike
>PCI devices, users are not allowed to use out-of-tree LSM modules which have to
>remain out-of-tree due to proposed-but-not-accepted by the upstream kernel.
>This is a serious bug; is LSM a proprietary/closed code where modification is
>impossible due to an End-User License Agreement?

You are way off in the weeds with false equivalencies.

>You have only three choices:
>
>  (1) allow assigning LSM ID integer value to all LSM modules (regardless of
>      whether that module was merged into upstream kernel)

We are not hardware manufacturers.

>  (2) use module name string value as LSM ID

This results is greater code complexity. If you see a way to do this, send a patch. Instead of unhelpfully saying "no, do it differently", show a solution.

>  (3) dynamically assign LSM ID integer value when an LSM module is registered

Again, send a patch.

>There never is fourth choice:
>
>  (4) assigning LSM ID integer value to only LSM modules which were merged
>      into upstream kernel
>
>The fourth choice is complete lockout of out of tree projects.

This is just not a real outcome. How is this any different from syscalls, capability bits, prctl values, ELF flags, etc?


-- 
Kees Cook