linux-kernel - Re: [PATCH 10/10] LSM: Blob sharing support for S.A.R.A and LandLock

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: <0288a057-8f38-665e-a1ac-34330d67412b@canonical.com>
Date:   Fri, 14 Sep 2018 11:23:36 -0700
From:   John Johansen <john.johansen@...onical.com>
To:     James Morris <jmorris@...ei.org>,
        Casey Schaufler <casey@...aufler-ca.com>
Cc:     Kees Cook <keescook@...omium.org>,
        Paul Moore <paul@...l-moore.com>,
        linux-security-module <linux-security-module@...r.kernel.org>,
        LKML <linux-kernel@...r.kernel.org>,
        SE Linux <selinux@...ho.nsa.gov>,
        Tetsuo Handa <penguin-kernel@...ove.sakura.ne.jp>,
        Stephen Smalley <sds@...ho.nsa.gov>,
        "linux-fsdevel@...r.kernel.org" <linux-fsdevel@...r.kernel.org>,
        Alexey Dobriyan <adobriyan@...il.com>,
        "Schaufler, Casey" <casey.schaufler@...el.com>
Subject: Re: [PATCH 10/10] LSM: Blob sharing support for S.A.R.A and LandLock

On 09/14/2018 11:18 AM, James Morris wrote:
> On Thu, 13 Sep 2018, Casey Schaufler wrote:
> 
>> On 9/13/2018 4:57 PM, Kees Cook wrote:
>>> On Thu, Sep 13, 2018 at 4:51 PM, Casey Schaufler <casey@...aufler-ca.com> wrote:
>>>> On 9/13/2018 4:06 PM, Kees Cook wrote:
>>>>> - what order should any stacking happen? Makefile? security=?
>>>> Makefile by default.
>>> Okay, if ordering is by Makefile and everyone dislikes my
>>> $lsm.enabled=0/1 thing, then these mean the same thing:
>>>
>>> security=selinux,tomoyo
>>> security=tomoyo,selinux
>>>
>>> i.e. order of security= is _ignored_ in favor of the Makefile ordering.
>>
>> No, I think that the two lines above should have a different
>> execution order. If we really need to specify multiple modules
>> at boot time that is what makes the most sense.
> 
> Agreed.
> 
> 
+1

partly because if order is ever going to be important, it needs to be
done now. It easy to loosen restrictions (ordering) in the future but
will be problematic to add it in.