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.
