On Tue, Oct 25, 2022 at 7:20 AM Tetsuo Handa
<penguin-kernel(a)i-love.sakura.ne.jp> 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