Messages in this thread | | | Subject | Re: [PATCH 16/18] LSM: Allow arbitrary LSM ordering | From | John Johansen <> | Date | Mon, 17 Sep 2018 16:25:08 -0700 |
| |
On 09/17/2018 04:10 PM, Mickaël Salaün wrote: >
<< snip >>
>>>>> If "lsm.enable=apparmor lsm.disable=apparmor" is specified the last value >>>>> specified is used giving "lsm.disable=apparmor". >>>>> >>>> makes sense >>> >>> The rules for modification are pretty obvious. The downside is, as >>> you point out, that they don't address ordering. Maybe we address that >>> directly: >>> >>> lsm.order=*,tomoyo >>> >>> TOMOYO should be last. >>> >>> lsm.order=apparmor,* >>> >>> AppArmor should be first. >>> >>> >>> lsm.order=*,sara,selinux,* >>> >>> SELinux should come directly after SARA but we otherwise don't care. >>> >>> lsm.order=smack,*,landlock,* >>> >>> Smack should be first and LandLock should come sometime later. >>> >>> lsm.order=*,yama,* >>> >>> Is meaningless. >>> >>> Modules not listed may go anywhere there is a "*" in the order. >>> An lsm.order= without a "*" is an error, and ignored. >>> If a module is specified in lsm.order but not built in it is ignored. >>> If a module is specified but disabled it is ignored. >>> The capability module goes first regardless. >>> >> >> I don't mind using lsm.order if we must but really do not like the '*' >> idea. It makes this way more complicated than it needs to be >> >> > > Landlock, because it target unprivileged users, should only be called > after all other major (access-control) LSMs. The admin or distro must > not be able to change that order in any way. This constraint doesn't > apply to current LSMs, though. >
And yet another complication :)
I don't know that we can enforce a strict only after all other LSMs. Imagine the hypothetical case of 2 LSMs targeting unprivileged users. Which one should be called first?
| |