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]

Date:   Tue, 23 Oct 2018 09:48:20 -0700
From:   Casey Schaufler <casey@...aufler-ca.com>
To:     Kees Cook <keescook@...omium.org>,
        John Johansen <john.johansen@...onical.com>
Cc:     Jordan Glover <Golden_Miller83@...tonmail.ch>,
        James Morris <jmorris@...ei.org>,
        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/12/2018 12:01 PM, Kees Cook wrote:
> On Friday, October 12, 2018 3:19 AM, John Johansen
> <john.johansen@...onical.com> wrote:
>> It isn't perfect but it manages consistency across distros as best as
>> can be achieved atm.
> Yeah, this is why I'm okay with the current series: it provides as
> consistent a view as possible, but leaves room for future improvements
> (like adding "+" or "!" or "all" or whatever).
>
> I'm curious to see what SELinux folks think of v5, though. I *think* I
> addressed all the concerns there, even Paul's "I want my distro
> default to not have extreme stacking" case too.
>
> -Kees

Looks like I should go on vacation more often. :)

I am generally opposed to fancy specification languages.
I support the explicit lsm= list specification because you
don't have to know any context to create a boot line that
will work, and be as close to what you've specified as possible
for the kernel configuration. One need look no further than
the mechanisms for setting POSIX ACLs for an example of
how to ensure a feature isn't used.

Had we the foresight to make security= take a list of
modules when Yama was added we might have avoided some of
this brouhaha, but there was no reason to expect that stacking
was ever going to happen back then.