Message-ID: <CACdnJutZFKX+izBxRYbyxefT5KrKhVV0XsymU=vBhywd+TOE3A@mail.gmail.com>
Date:   Tue, 03 Apr 2018 23:45:50 +0000
From:   Matthew Garrett <mjg59@...gle.com>
To:     Linus Torvalds <torvalds@...ux-foundation.org>
Cc:     luto@...nel.org, David Howells <dhowells@...hat.com>,
        Ard Biesheuvel <ard.biesheuvel@...aro.org>, 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>,
        jforbes@...hat.com, linux-man@...r.kernel.org, jlee@...e.com,
        LSM List <linux-security-module@...r.kernel.org>,
        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 4:26 PM Linus Torvalds
<torvalds@...ux-foundation.org>
wrote:

> On Tue, Apr 3, 2018 at 4:17 PM, Matthew Garrett <mjg59@...gle.com> wrote:
> >
> > 1) Secure Boot is intended to permit the construction of a boot chain
that
> > only runs ring 0 code that the user considers trustworthy

> No.

> That may be *one* intention, for some people.

> It's not an a-priori one for the actual user.

Secure Boot is intended to *permit* that. Without Secure Boot you're unable
to do that. Some users want that. Some users don't.

> > 2) Allowing arbitrary user code to run in ring 0 without affirmative
> > consent on the part of the user is therefore incompatible with the
goals of
> > Secure Boot

> Again, that has absolutely zero relevance.

> Those goals are not the *users* goals.

> Be honest now. It wasn't generally users who clamored for it.

If you ask a user whether they want a system that lets an attacker replace
their kernel or one that doesn't, what do you think their answer is likely
to be?

> If the user actually wanted it, and is asking for it, he can enable
> it. Independently of secure boot, which the user generally has little
> control over.

How? If the bootloader will boot kernels that don't impose this restriction
then an attacker just replaces whatever's enabling that feature. And, uh,
seriously, I've been asking for *years* for someone to point me at a PC on
the market that doesn't give the user control over Secure Boot, but Shim
was expressly designed to ensure that the user would have the ability to
enroll additional trusted keys (or disable signature validation entirely),
so which cases are you thinking of where the user doesn't have control?

> > 3) This patchset provides a mechanism to alter the behaviour of the
kernel
> > such that it is significantly more difficult for arbitrary user code to
run
> > in ring 0 without affirmative user consent

> That difficulty already exists, the new thing isn't somehow related to
> that at all.

> Look at our "uyou can only load modules if you're root" rules. Or the
> "you can only load modules if they are signed".

> See a pattern there? They don't magically enable themselves (or
> disable themselves) depending on whether you booted with secure boot
> or not.

What's the benefit of "You can only load modules if they are signed" if
root is able to just overwrite that policy bit in the kernel? The split
between unprivileged users and root is real, but right now module
signatures are theater - there's no significant security benefit from them.
But the reason to tie this to Secure Boot is that without that an attacker
who has root can just replace the kernel on disk (or patch the bootloader
to live-patch the kernel on boot, and yes that's an attack we've seen in
the real world), so while it's a feature that is arguably beneficial under
all circumstances it's a feature that only has significant benefit if you
have some way to actually validate what you're booting in the first place.

> > 4) Providing a mechanism for automatically enabling this behaviour when
> > running in a context that is intended to restrict access to ring 0 is a
> > rational thing to do, because otherwise it is difficult to achieve the
> > objective in (1)

> No. See why it's *NOT* rational, as explained already several times.

> Magically changing kernel behavior depending on some subtle and often
> unintentional bootup behavior detail is completely idiotic.

> It would be idiotic if it was that "check kernel module signatures"
> check. This is no less idiotic.

> Seriously, listen to your own arguments. If they don't make sense for
> checking kernel module signatures, why the hell would they make sense
> for something like lockdown.

> THE TWO THINGS ARE ENTIRELY INDEPENDENT.

Again, what is your proposed mechanism for ensuring that off the shelf
systems can be configured in a way that makes this possible?

Powered by blists - more mailing lists