linux-kernel - Re: Linux 5.1-rc2

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: <d067619e-8c7f-94ec-a835-fc86d1b449e3@schaufler-ca.com>
Date:   Wed, 27 Mar 2019 15:23:07 -0700
From:   Casey Schaufler <casey@...aufler-ca.com>
To:     Tetsuo Handa <penguin-kernel@...ove.sakura.ne.jp>,
        Kees Cook <keescook@...omium.org>
Cc:     James Morris <jmorris@...ei.org>,
        Randy Dunlap <rdunlap@...radead.org>,
        Linus Torvalds <torvalds@...ux-foundation.org>,
        Linux List Kernel Mailing <linux-kernel@...r.kernel.org>,
        linux-security-module <linux-security-module@...r.kernel.org>,
        Jakub Kicinski <jakub.kicinski@...ronome.com>
Subject: Re: Linux 5.1-rc2

On 3/27/2019 3:05 PM, Tetsuo Handa wrote:
> On 2019/03/28 6:43, Kees Cook wrote:
>>>> I don't see problems for an exclusive LSM user (AA, SELinux, Smack)
>>>> also initializing TOMOYO, though. It should be a no-op. Is there some
>>>> situation where this is not true?
>>> There should be no problem except some TOMOYO messages are printed.
>> Okay, so I should send my latest version of the patch to James? Or do
>> you explicitly want TOMOYO removed from all the CONFIG_LSM default
>> lines except when selected by CONFIG_DEFAULT_SECURITY_TOMOYO? (I worry
>> the latter will lead to less testing of the stacking.)
>>
> My approach is "opt-in" while your approach is "opt-out". And the problem
> here is that people might fail to change CONFIG_LSM from the default value
> to what they need. (And Jakub did not change CONFIG_LSM to reflect
> CONFIG_DEFAULT_SECURITY_APPARMOR from the old config.) Thus, I suggest
> "opt-in" approach; which includes up to only one legacy major LSM and allows
> people to change the default value to include multiple legacy major LSMs.
>
> You can propose your latest version. If SELinux/Smack/AppArmor people
> prefer "opt-out" approach, I'm fine with "opt-out" approach.

In the long haul we want people to use CONFIG_LSM to set their
list of modules. Providing a backward compatible CONFIG_DEFAULT_SECURITY_BLAH
makes some sense, but it's important that we encourage a mindset change.
Maybe with CONFIG_DEFAULT_SECURITY_LIST with a a full list, which uses the
value from CONFIG_LSM, and make it the default?