LSM stacking in next for 6.1?

[Casey Schaufler]

On 10/25/2022 4:20 AM, Tetsuo Handa 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).
>
> It will be a complete reinvention of Linux security framework which is
> merely borrowing hooks provided by LSM. That is no different from
> duplicating existing LSM hooks and managing via completely different
> set of interfaces (e.g. /proc/$pid/attr2/$lsmname/$filename ,
> /sys/kernel/security2/$lsmname/$filename ). Such implementation is
> no longer loadable LSM. It is LSM version 2. And I don't think that
> such implementation will be accepted unless you agree to kill current
> LSM (say, LSM version 1).

The counter argument to this statement is that BPF has been accepted
upstream. eBPF programs are different from built-in security modules.
There is no reason that a well implemented LSM that accepts loadable
modules *that are different* from built-in modules couldn't be created.
I seriously doubt that it would get upstream for all the reasons
usually cited. But there is nothing about the implementation I've proposed
that would prevent it.