Re: [GIT PULL] Kernel lockdown for secure boot

[Andy Lutomirski <luto@kernel.org>]

On Tue, Apr 3, 2018 at 5:17 PM, Jann Horn <jannh@google.com> wrote:
> On Wed, Apr 4, 2018 at 2:06 AM, Linus Torvalds
> <torvalds@linux-foundation.org> wrote:
>> On Tue, Apr 3, 2018 at 4:59 PM, Matthew Garrett <mjg59@google.com> wrote:
>>>
>>> Ok. So we can build distribution kernels that *always* have this on, and to
>>> turn it off you have to disable Secure Boot and install a different kernel.
>>
>> Bingo.
>>
>> Exactly like EVERY OTHER KERNEL CONFIG OPTION.
>>
>> Just like all the ones that I've mentioned several times.
>>
>> Or, like a lot of other kernel options, maybe have a way to just
>> disable it on the kernel command line, and let the user know about it.
>>
>> That would still be better than disabling secure boot entirely in your
>> world view, so it's (a) more convenient and (b) better.
>>
>> Again, in no case does it make sense to tie it into "how did we boot".
>> Because that's just inconvenient for everybody.
>
> Without taking a stance regarding whether I think that kernel lockdown
> makes sense, I think Matthew's point is this:
> If you don't have lockdown, secure boot doesn't provide a benefit,
> since an attacker could just modify the init binary instead of messing
> with your kernel.
> If you have secure boot, you want lockdown to prevent chainloading
> into a backdoored version of the real OS.

I don't think that's the argument here.  Secure boot can be used to
protect initramfs, since initramfs comes from the secure boot-verified
bootloader.  That verified initramfs can protect the init binary.

As far as I can tell, what's really going on here is that there's a
significant contingent here that wants to prevent Linux from
chainloading something that isn't Linux.  (There doesn't seem to be a
real benefit to preventing Linux from chainloading Linux, since the
chainloaded Linux is unlikely to let the attacker do much that the
original rooted Linux kernel wouldn't have allowed.)  In particular,
Microsoft, which de facto controls most of the secure boot key
ecosystem, doesn't want Windows to be chainloaded without having its
signature verified.

I admit I'm not quite sure why Microsoft considers this important.
They already require a TPM for all new systems, and any important
secrets can be sealed by the TPM such that a maliciously chainloaded
Windows kernel couldn't access those secrets.  But secure boot
predates the WHQL TPM requirement if I remember correctly, and I
suspect that we're seeing leftover requirements from
secure-boot-but-no-TPM era.