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  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 11:50:21 -0700
From:   Kees Cook <keescook@...omium.org>
To:     Casey Schaufler <casey@...aufler-ca.com>
Cc:     John Johansen <john.johansen@...onical.com>,
        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 Tue, Oct 23, 2018 at 9:48 AM, Casey Schaufler <casey@...aufler-ca.com> wrote:
> 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.

This sounds like an "Ack" for you? :) I'll harass everyone in person
in a couple days.

Did you poke around at my combined series?
https://git.kernel.org/pub/scm/linux/kernel/git/kees/linux.git/log/?h=lsm/ordering-v6-blob-sharing

-Kees

-- 
Kees Cook
Pixel Security

Powered by blists - more mailing lists