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.
