linux-kernel - Re: [PATCH security-next v5 00/30] LSM: Explict 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: <f68e5f4b-6360-a9e7-597f-89d1d3ca73c1@canonical.com>
Date:   Thu, 11 Oct 2018 16:48:14 -0700
From:   John Johansen <john.johansen@...onical.com>
To:     Kees Cook <keescook@...omium.org>,
        Jordan Glover <Golden_Miller83@...tonmail.ch>
Cc:     James Morris <jmorris@...ei.org>,
        Casey Schaufler <casey@...aufler-ca.com>,
        Stephen Smalley <sds@...ho.nsa.gov>,
        Paul Moore <paul@...l-moore.com>,
        Tetsuo Handa <penguin-kernel@...ove.sakura.ne.jp>,
        Mimi Zohar <zohar@...ux.vnet.ibm.com>,
        Randy Dunlap <rdunlap@...radead.org>,
        LSM <linux-security-module@...r.kernel.org>,
        "open list:DOCUMENTATION" <linux-doc@...r.kernel.org>,
        linux-arch <linux-arch@...r.kernel.org>,
        LKML <linux-kernel@...r.kernel.org>
Subject: Re: [PATCH security-next v5 00/30] LSM: Explict ordering

On 10/11/2018 04:09 PM, Kees Cook wrote:
> On Thu, Oct 11, 2018 at 3:58 PM, Jordan Glover
> <Golden_Miller83@...tonmail.ch> wrote:
>> On Thursday, October 11, 2018 7:57 PM, Kees Cook <keescook@...omium.org> wrote:
>>>     To switch to SELinux at boot time with
>>>     "CONFIG_LSM=yama,loadpin,integrity,apparmor", the old way continues to
>>>     work:
>>>
>>>     selinux=1 security=selinux
>>>
>>>     This will work still, since it will enable selinux (selinux=1) and
>>>     disable all other major LSMs (security=selinux).
>>>
>>>     The new way to enable selinux would be using
>>>     "lsm=yama,loadpin,integrity,selinux".
>>>
>>
>> It seems to me that legacy way is more user friendly than the new one.
>> AppArmor and SElinux are households names but the rest may be enigmatic
>> for most users and the need for explicit passing them all may be
>> troublesome. Especially when the new ones like sara,landlock or cows :)
>> will be incoming. Moreover to knew what you have to pass there, you need
>> to look at CONFIG_LSM in kernel config (which will vary across distros
>> and also mean copy-paste from the web source may won't work as expected)
>> which again most users don't do.
>>
>> I think there is risk that users will end up with "lsm=selinux" without
>> realizing that they may disable something along the way.
>>
>> I would prefer for "lsm=" to work as override to "CONFIG_LSM=" with
>> below assumptions:
>>
>> I. lsm="$lsm" will append "$lsm" at the end of string. Before extreme
>> stacking it will also remove the other major (explicit) lsm from it.
>>
>> II. lsm="!$lsm" will remove "$lsm" from the string.
>>
>> III. If "$lsm" already exist in the string, it's moved at the end of it
>> (this will cover ordering).
> 
> We've had things sort of like this proposed, but if you can convince
> James and others, I'm all for it. I think the standing objection from
> James and John about this is that the results of booting with
> "lsm=something" ends up depending on CONFIG_LSM= for that distro. So
> you end up with different behaviors instead of a consistent behavior
> across all distros.
> 

Its certainly a point that could confuse the user. I do have concerns
about it, but not something that is on a must haves list

> Now, in the future blob and extreme stacking world, having the
> explicit lsm= list shouldn't be too bad since LSMs will effectively
> ALL be initialized -- but they'll be inactive since they have no
> policy loaded.
> 

you are more optimistic about this than I am, but there will be at
least some movement towards this.

> But I still agree with you: I'd like a friendlier way to
> disable/enable specific LSMs, but an explicit lsm= seems to be the
> only way.
> 

Hrmmm, I don't know about the only way, but a way to provide the
explicit list, and also set a specific set as the default in the
Kconfig is a hard requirement.

The initial lsm.ebable, lsm.disable had too many issues, and for
various reasons I never managed to get back to kees' proposal
for using +.

That said, I do think the right approach for the initial pass is
the explicit list. It moves the arguments to the side and allows
this work to move forward.

>> It's possible that something lime this was discussed already
>> but without full examples it was hard to me for tracking things.
> 
> It's been a painful thread. ;)
> 

Indeed