linux-kernel - Re: [PATCH v8 16/17] integrity: Trust MOK keys if MokListTrustedRT found

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:   Thu, 10 Nov 2022 09:15:11 -0500
From:   James Bottomley <James.Bottomley@...senPartnership.com>
To:     Morten Linderud <morten@...derud.pw>,
        Eric Snowberg <eric.snowberg@...cle.com>
Cc:     keyrings@...r.kernel.org, linux-integrity@...r.kernel.org,
        zohar@...ux.ibm.com, dhowells@...hat.com, dwmw2@...radead.org,
        herbert@...dor.apana.org.au, davem@...emloft.net,
        jarkko@...nel.org, jmorris@...ei.org, serge@...lyn.com,
        keescook@...omium.org, torvalds@...ux-foundation.org,
        weiyongjun1@...wei.com, nayna@...ux.ibm.com, ebiggers@...gle.com,
        ardb@...nel.org, nramas@...ux.microsoft.com, lszubowi@...hat.com,
        jason@...c4.com, linux-kernel@...r.kernel.org,
        linux-crypto@...r.kernel.org, linux-efi@...r.kernel.org,
        linux-security-module@...r.kernel.org, pjones@...hat.com,
        konrad.wilk@...cle.com
Subject: Re: [PATCH v8 16/17] integrity: Trust MOK keys if MokListTrustedRT
 found

On Thu, 2022-11-10 at 01:01 +0100, Morten Linderud wrote:
[...]
> efi_mokvar_entry_find doesn't simply read an UEFI variable as the
> commit message suggests, it will look for the MOK variable loaded
> into the EFI configuration table. This implies we need this table
> setup in early boot to take usage of this patch set.
> 
> The only bootloader that does setup this table, is the `shim` as
> described. But no other bootloader implements support for the MOK EFI
> configuration table.

Just to be precise: shim isn't a boot loader.  It's a trust pivot
device away from the built in UEFI keys to the Machine Owner Keys. 
Shim is designed to be used with another bootloader like grub or sd-
boot.  Now you could load a kernel directly with shim, in the same way
you could load it directly from UEFI, but that doesn't make it a
bootloader.

> 
> This effectively means that there is still no way for Machine Owners
> to load keys into the keyring, for things like module signing,
> without the shim present in the bootchain. I find this a bit weird.
> 
> Is this an intentional design decision, or could other ways be
> supported as well?

Yes, rather than try to have all bootloaders conform to the MoK
protocol, it's easier to implement it in a single purpose component
that can be used with any of them.  Essentially if you want to rely on
the UEFI keys and not do an MoK pivot (as some people do) then you can
remove shim from the sequence.

In many ways that's part of the problem with this patch set: The
underlying assumption is everyone does this trust pivot.  If you don't
do this trust pivot (I don't for instance, having replaced my UEFI keys
with my own) you can't add keys to the kernel this way.  However, how
would the kernel know whether you trust the UEFI keys or not?  The
other problem is that without the shim protocol being present, grub
can't check the kernel signature, which means that even if you do own
your own UEFI keys, you need something to replace shim, like:

https://git.kernel.org/pub/scm/linux/kernel/git/jejb/efitools.git/tree/ShimReplace.c

James