LSM stacking in next for 6.1?

Paul Moore paul at paul-moore.com
Wed Oct 26 20:11:21 UTC 2022


On Tue, Oct 25, 2022 at 7:20 AM Tetsuo Handa
<penguin-kernel at 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



More information about the Linux-security-module-archive mailing list