On 10/25/2022 3:12 PM, Tetsuo Handa wrote: > On 2022/10/25 23:12, Casey Schaufler wrote: >> 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. >> > As an easy example, please show me an eBPF program that allows restricting where > to chroot to and allows configuring where to chroot to using /sys/kernel/security/ > interface. > > An loadable LSM consists of hooks (for filtering access requests) and interface > (for configuring rules whether to filter access requests). > > Your LSM id approach makes it impossible to use interface (due to lack of LSM id > for loadable LSM modules) by loadable LSM modules. LSM id must not be limited to > built-in LSM modules. I'm sorry that I am failing to communicate my understanding of why this isn't true. You need a built-in LSM that loads and manages loadable security modules. That LSM would have an LSM ID just like the BPF LSM has a LSM ID. I have no doubt that there are multiple workable implementations, as I have looked into many different ways to implement the stacking for built-in modules. I am also sorry that I don't expect to have enough working years left to even consider spending any more time on the problem. This is a development effort for The Next Generation.
