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 for Android: free password hash cracker in your pocket
[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <20221110000129.kl6pjy5mafpuptbk@framework>
Date:   Thu, 10 Nov 2022 01:01:29 +0100
From:   Morten Linderud <morten@...derud.pw>
To:     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,
        James.Bottomley@...senpartnership.com, pjones@...hat.com,
        konrad.wilk@...cle.com
Subject: Re: [PATCH v8 16/17] integrity: Trust MOK keys if MokListTrustedRT
 found

On Tue, Nov 23, 2021 at 11:41:23PM -0500, Eric Snowberg wrote:
> 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.

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?

-- 
Morten Linderud
PGP: 9C02FF419FECBE16

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ