linux-kernel - Re: [PATCH 16/18] LSM: Allow arbitrary LSM ordering

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <8a11b293-6094-0b5e-5e75-3a9709a2bd00@canonical.com>
Date:   Mon, 17 Sep 2018 16:25:08 -0700
From:   John Johansen <john.johansen@...onical.com>
To:     Mickaël Salaün <mic@...ikod.net>,
        Casey Schaufler <casey@...aufler-ca.com>,
        Kees Cook <keescook@...omium.org>
Cc:     James Morris <jmorris@...ei.org>,
        Tetsuo Handa <penguin-kernel@...ove.sakura.ne.jp>,
        Paul Moore <paul@...l-moore.com>,
        Stephen Smalley <sds@...ho.nsa.gov>,
        "Schaufler, Casey" <casey.schaufler@...el.com>,
        LSM <linux-security-module@...r.kernel.org>,
        LKLM <linux-kernel@...r.kernel.org>
Subject: Re: [PATCH 16/18] LSM: Allow arbitrary LSM ordering

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?