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).
