On 10/30/2022 9:37 AM, Kees Cook wrote: > On October 30, 2022 7:02:52 AM PDT, Tetsuo Handa <penguin-kernel@xxxxxxxxxxxxxxxxxxx> 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? > Loadability and the LSM ID are completely separate issues. Show me a patch that implements loading modules and I will show you how to change it to accommodate the LSM ID. That is, if it isn't obvious at that point.
