linux-kernel - Re: [GIT PULL] Kernel lockdown for secure boot

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, 3 Apr 2018 15:53:04 -0700
From:   Andy Lutomirski <luto@...nel.org>
To:     Matthew Garrett <mjg59@...gle.com>
Cc:     Linus Torvalds <torvalds@...ux-foundation.org>,
        Andrew Lutomirski <luto@...nel.org>,
        David Howells <dhowells@...hat.com>,
        Ard Biesheuvel <ard.biesheuvel@...aro.org>,
        James Morris <jmorris@...ei.org>,
        Alan Cox <gnomes@...rguk.ukuu.org.uk>,
        Greg Kroah-Hartman <gregkh@...uxfoundation.org>,
        Linux Kernel Mailing List <linux-kernel@...r.kernel.org>,
        Justin Forbes <jforbes@...hat.com>,
        linux-man <linux-man@...r.kernel.org>, joeyli <jlee@...e.com>,
        LSM List <linux-security-module@...r.kernel.org>,
        Linux API <linux-api@...r.kernel.org>,
        Kees Cook <keescook@...omium.org>,
        linux-efi <linux-efi@...r.kernel.org>
Subject: Re: [GIT PULL] Kernel lockdown for secure boot

On Tue, Apr 3, 2018 at 3:51 PM, Matthew Garrett <mjg59@...gle.com> wrote:
> On Tue, Apr 3, 2018 at 3:46 PM Linus Torvalds
> <torvalds@...ux-foundation.org>
> wrote:
>
>> For example, I love signed kernel modules. The fact that I love them
>> has absolutely zero to do with secure boot, though. There is
>> absolutely no linkage between the two issues: I use (self-)signed
>> kernel modules simply because I think it's a good thing in general.
>
>> The same thing is true of some lockdown patch. Maybe it's a good thing
>> in general. But whether it's a good thing is _entirely_ independent of
>> any secure boot issue. I can see using secure boot without it, but I
>> can very much also see using lockdown without secure boot.
>
>> The two things are simply entirely orthogonal. They have _zero_
>> overlap. I'm not seeing why they'd be linked at all in any way.
>
> Lockdown is clearly useful without Secure Boot (and I intend to deploy it
> that way for various things), but I still don't understand why you feel
> that the common case of booting a kernel from a boot chain that's widely
> trusted derives no benefit from it being harder to subvert that kernel into
> subverting that boot chain. For cases where you're self-signing and feel
> happy about that, you just set CONFIG_LOCK_DOWN_IN_EFI_SECURE_BOOT to n and
> everyone's happy?

I would like to see distros that want Secure Boot to annoy users by
enabling Lockdown be honest about the fact that it's an annoyance and
adds very little value by having to carry a patch that was rejected by
the upstream kernel.

-Andy