Re: [PATCH RFC 0/1] module: Optionally use .platform keyring for signatures verification

[Mimi Zohar <zohar@linux.ibm.com>]

On Mon, 2025-06-02 at 15:25 +0200, Vitaly Kuznetsov wrote:
> UEFI SecureBoot 'db' keys are currently not trusted for modules signatures
> verification. RedHat based downstream distros (RHEL, Fedora, ...) carry a
> patch changing that for many years (since 2019 at least). This RFC is an
> attempt to upstream it as the functionality seems to be generally useful.
> 
> Previously, pre-boot keys (SecureBoot 'db', MOK) were not trusted within
> kernel at all. Things have changed since '.machine' keyring got introduced
> making MOK keys optionally trusted.

The changes were made incrementally:

The original trust model relied on the secure boot signature chain of trust.
After pivoting root, only keys that were built into the kernel were trusted. 
Anyone building a kernel could embed their keys in the kernel image, but there
was no way of loading other keys.

- The original exception was for verifying the kexec kernel image.  For that
reason and that reason alone, the pre-boot keys were loaded onto the platform
keyring.

- From an IMA perspective, the second exception allowed loading public keys
needed for verifying locally signed code.  The first attempt stored and loaded
keys from the TPM.  (Unfortunately) instead, what was upstreamed was loading
public keys stored in MOK.  There's an option to only load CA certificates
stored in MOK, which would be "safer".

Changing the existing behavior will impact everyone's security/integrity
assumptions of the existing system trusted keyrings. 

What's clear today is that we need finer key granularity than at the level of
keyrings.

Mimi

> Before that, there was a discussion to
> make .platform trusted by default:
> https://lore.kernel.org/lkml/1556116431-7129-1-git-send-email-robeholmes@gmail.com/
> which didn't go very far because the assumption was that this is only useful
> when the user has control over 'db'. I believe there's a fairly common
> use-case where this is true.
> 
> The use-case: virtualized and cloud infrastructure generally provide an
> ability to customize SecureBoot variables, in particular, it is possible
> to bring your own SecureBoot 'db'. This may come handy when a user wants to
> load a third party kernel module (self built or provided by a third party
> vendor) while still using a distro provided kernel. Generally, distro
> provided kernels sign modules with an ephemeral key and discard the private
> part during the build. While MOK can sometimes be used to sign something
> out-of-tree, it is a tedious process requiring either a manual intervention
> with shim or a 'certmule' 
> (see https://blogs.oracle.com/linux/post/the-machine-keyring). In contrast,
> the beauty of using SecureBoot 'db' in this scenario is that for public
> clouds and virtualized infrastructure it is normally a property of the OS
> image (or the whole infrastructure/host) and not an individual instance;
> this means that all instances created from the same template will have 'db'
> keys in '.platform' by default.
> 
> The suggested approach is not to change the default, but to introduce a
> Kconfig variable (CONFIG_MODULE_SIG_PLATFORM) doing the job. Note, the 
> kernel already trusts '.platform' for kexec (see commit 278311e417be 
> ("kexec, KEYS: Make use of platform keyring for signature verify"))
> and dm-verity (see commit 6fce1f40e951 ("dm verity: add support for
> signature verification with platform keyring")) so maybe changing the
> default or introducing a generic '.plarform is fully trusted' option
> would actually be better.
> 
> Vitaly Kuznetsov (1):
>   module: Make use of platform keyring for module signature verify
> 
>  Documentation/admin-guide/module-signing.rst |  6 ++++++
>  kernel/module/Kconfig                        | 11 +++++++++++
>  kernel/module/signing.c                      |  9 ++++++++-
>  security/integrity/Kconfig                   |  2 +-
>  4 files changed, 26 insertions(+), 2 deletions(-)
>