On Tue, Oct 25, 2022 at 7:20 AM Tetsuo Handa <[email protected]> wrote: > On 2022/10/25 19:26, John Johansen wrote: > > no, Casey is not. He is trying to find a path forward to get LSM > > stacking upstream sooner than later. He has made proposals that > > admittedly you have not liked, but he has at least tried to propose > > ideas that could work within the insane set of constraints. > > I'm OK with getting LSM stacking upstream. But changes made based on > only built-in modules are bad. If LSM id cannot be assigned to loadable > LSM modules at runtime because not all loadable LSM modules will be > in-tree in order to get an LSM id assigned, loadable LSM modules won't > be able to utilize e.g. lsm_module_list system call (or whatever > changes made while trying to unshare resources/interfaces currently > shared among SELinux/Smack/AppArmor).
As a reminder, the LSM layer, just like the rest of the kernel, has no plans to provide any level of consideration or support for out-of-tree kernel code. LSMs which are not part of the upstream Linux kernel are not our concern here; if they fail to work with the syscall and/or LSM stacking changes merged, that should not be considered a blocker to upstream development. -- paul-moore.com -- Linux-audit mailing list [email protected] https://listman.redhat.com/mailman/listinfo/linux-audit
