Re: [GIT PULL] Kernel lockdown for secure boot

[Linus Torvalds <torvalds@linux-foundation.org>]

On Tue, Apr 3, 2018 at 6:13 PM, Matthew Garrett <mjg59@google.com> wrote:
>
> There are four cases:

No.

Matthew., stop with the agenda already.

This shit is what I'm talking about:

> Verified Boot off, lockdown on: Perception of security improvement that's
> trivially circumvented (and so bad)

You're doing some serious value judgement that is simply bogus.

If lockdown actually helps avoid CPL0 execution attacks, then it helps
even if secure more is off.

Sure, you can do things like try to install kernels and reboot, but
honestly, that's not "trivially circumvented". It can be quite hard to
hide even if you don't have secure boot. Things like disk encryption
(common for a lot of people) for example means that you simply won't
be booting that machine without the user noticing.

Or think of virtual machines - which people often use on purpose for
security things. Again, they very much are _not_ going to have secure
boot, but it's not necessarily even possible to "replace the kernel
and reboot" at all, because the kernel came from outside the virtual
machine entirely, and rebooting might just kill the VM rather than
restart anything.

So I really think you're pushing this whole "not secure boot" means
"trivial circumvention" much much too hard.

To the point of it being an outright lie.

I think the kind of people who run stuff in virtual machines could
easily want to also enable lockdown measures, simply to reduce the
attack window within that VM. Wouldn't you agree? Those are often
security-conscious people.

This is what I mean by having an agenda.  We all know you are a big
proponent of secure boot. But it seems to cloud your arguments, by
turning your assumptions and your agenda into an "argument" that is
simply not even TRUE.

See what I'm unhappy about?

> Verified Boot on, lockdown off: Perception of security improvement that's
> trivially circumvented (and so bad), status quo in mainline kernels

I think this is entirely false too. Again, the "trivial circumvention"
shows a bias and agenda that isn't really all that true.

> Of these four options, only two make sense.

No.

You say that, because you have that bias and that agenda.

But that simply doesn't make it true.

Now, what actually seems to be a real and valid argument is *this* part:

> This makes it easy for a user to switch
> between the two states that make sense by running a single command and then
> following some prompts on the next reboot. The alternative would be to
> provide a signed kernel that always enabled lockdown and an unsigned kernel
> that didn't, which would (a) increase load on distributions and (b) force
> users to both run mokutil --disable-validation and also install a different
> kernel.

THAT is an actual argument. Admittedly I think it's a horrible hack,
but it's a hack that can be explained without outright lying. And it
may be a hack that is "the best we can reasonably do"

See what I'm saying?

One argument is based on your value judgments that not everybody else
believes in.

The other argument is based purely on cold hard particular facts.

Guess which argument is better for people who aren't Matthew Garrett?

That said, wouldn't it be equally good to just make the whole thing be
a protected EFI variable instead? Once you have physical access to the
EFI shell (to turn off secure boot) you have access to that too.

Which would allow the "switch off/on" case even if there are other
reasons why changing secure boot isn't a great option (possibly
because secure boot isn't an option to begin with due to being so
invonvenient).

              Linus