[PATCH 16/18] LSM: Allow arbitrary LSM ordering

[John Johansen]

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?