On Thu, Nov 10, 2022 at 08:42:08AM +0100, Ard Biesheuvel wrote:

On Thu, 10 Nov 2022 at 01:01, Morten Linderud [off-list ref] wrote:

quoted

On Tue, Nov 23, 2021 at 11:41:23PM -0500, Eric Snowberg wrote:

quoted

A new Machine Owner Key (MOK) variable called MokListTrustedRT has been
introduced in shim. When this UEFI variable is set, it indicates the
end-user has made the decision themselves that they wish to trust MOK keys
within the Linux trust boundary.  It is not an error if this variable
does not exist. If it does not exist, the MOK keys should not be trusted
within the kernel.

Hi Eric,

I've been milling around on this patch-set for a while and I have a few issues
with the description of the commit and what the code actually does.

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.

Does any other bootloader implement support for the (volatile)
MokListTrustedRT variable?

No. The efforts seems to be mostly focused on supporting a setup where shim
boots grub. Anything besides this has never really been important for the people
writing it.

The main reason for the email is to try and figure out what the EFI
configuration table adds to the threat model.

Note that this variable is intentionally volatile, and should be
rejected by the kernel if it is not. The point of these RT variables
or the config tables is that they can only be set at boot if a signed
and therefore trusted agent created them.

So the only trusted agent currently is the shim? It claims to be a "trivial EFI
application" but the interplay between mokutils and shim isn't documented and
not trivial to understand.

Permitting non-volatile variables here defeats the purpose of secure
boot, which aims to prevent exploits from gaining persistence. It
would be bad if you could corrupt the trusted boot chain forever by
setting a variable once.

Would this change if the variable could be read from the EFI configuration table
or as an EFI variable? Instead of the current situation where we only support
the configuration table?

quoted

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.

I assume it's a yes to "intentional design decision", and my followup question
to this would be to ask where it's documented?

If we are looking for a way to use EFI variables to inject additional
certificates into the keyring without the ability to authenticate
them, we should I'd strongly recommend that we disable that by default
and add a big fat warning that it is incompatible with the guarantees
secure boot aims to provide.

The present features are all disabled by default I believe?

Most of this seems to be knowledge residing between a few people that was
present at the implementation, and as a user-space tool author comming into this
10 years later, it's really hard to figure out how a lot of these decisions came
to be.

-- 
Morten Linderud
PGP: 9C02FF419FECBE16