Re: LSM stacking in next for 6.1?
Kees Cook <[email protected]>
| Newsgroups | com.redhat.linux-audit,org.kernel.vger.linux-security-module,org.kernel.vger.selinux |
|---|---|
| Message-ID | <[email protected]> |
On October 30, 2022 7:02:52 AM PDT, Tetsuo Handa <[email protected]> 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 -- Linux-audit mailing list [email protected] https://listman.redhat.com/mailman/listinfo/linux-audit