[PATCH] Revert "integrity: Do not load MOK and MOKx when secure boot be disabled"

[PATCH] Revert "integrity: Do not load MOK and MOKx when secure boot be disabled"

[Lennart Poettering]

This reverts commit 92ad19559ea9a8ec6f158480934ae26ebfe2c14f.

This original commit this reverts creates a strange situation: it
ensures more restrictive behaviour if SecureBoot is off then when it
is on, which is the opposite of what one would expect.

Typically, one would expect that if SB is off the validation of
resources during the pre-kernel and kernel initialization is less
restrictive, not more restrictive. But this check turned the world on
its head.

I'd like to ask for this commit to be reverted. If SB is on all bets are
off regarding integrity of boot loaders and stuff, hence it makes no
sense to be restrictive here: you cannot regain integrity once you gave
it up once, hence if all bets are off anyway we might as well import any
Mok keys passed to us into the kernel keyring.

Or to say this differently: if an attacker got control of the pre-kernel
boot phase they might as well patch around in the firmware apis to make
the kernel believe it is in SB mode even if it is not. Hence the check
carries no value. It doesn't protect anything in any effective way.

The reason i'd like this check to go is that I'd like a nice way to
insert keys from pre-boot into into the kernel keyring for use with
signed dm-verity, without requiring recompilation of the kernel, and
without SB database games. i.e. i'd like to use a regular, signed
distro kernel, and pass to it additional keys to insert into the
kernel keyring in a reasonable way. The mok stuff would be great for that,
except it all falls apart once SB is off.

You might wonder what signed dm-verity gives me if I have SB off. If
we authenticate the boot phase up to Linux userspace via TPM-based PCR
policies (i.e. measured boot) we can be sure of the boot integrity
without having to rely on SB. But then we'd still like to use
dm-verity based code signing for userspace.
---
 security/integrity/platform_certs/load_uefi.c | 5 -----
 1 file changed, 5 deletions(-)

diff --git a/security/integrity/platform_certs/load_uefi.c b/security/integrity/platform_certs/load_uefi.c
index d1fdd113450a..7783bcacd26c 100644
--- a/security/integrity/platform_certs/load_uefi.c
+++ b/security/integrity/platform_certs/load_uefi.c
@@ -7,7 +7,6 @@
 #include <linux/err.h>
 #include <linux/efi.h>
 #include <linux/slab.h>
-#include <linux/ima.h>
 #include <keys/asymmetric-type.h>
 #include <keys/system_keyring.h>
 #include "../integrity.h"
@@ -211,10 +210,6 @@ static int __init load_uefi_certs(void)
 		kfree(dbx);
 	}

-	/* the MOK/MOKx can not be trusted when secure boot is disabled */
-	if (!arch_ima_get_secureboot())
-		return 0;
-
 	mokx = get_cert_list(L"MokListXRT", &mok_var, &mokxsize, &status);
 	if (!mokx) {
 		if (status == EFI_NOT_FOUND)
--
2.48.1


Lennart

--
Lennart Poettering, Berlin

Re: [PATCH] Revert "integrity: Do not load MOK and MOKx when secure boot be disabled"

[Jarkko Sakkinen]

On Thu, Mar 20, 2025 at 01:02:13PM +0100, Lennart Poettering wrote:
> diff --git a/security/integrity/platform_certs/load_uefi.c b/security/integrity/platform_certs/load_uefi.c
> index d1fdd113450a..7783bcacd26c 100644
> --- a/security/integrity/platform_certs/load_uefi.c
> +++ b/security/integrity/platform_certs/load_uefi.c
> @@ -7,7 +7,6 @@
>  #include <linux/err.h>
>  #include <linux/efi.h>
>  #include <linux/slab.h>
> -#include <linux/ima.h>
>  #include <keys/asymmetric-type.h>
>  #include <keys/system_keyring.h>
>  #include "../integrity.h"
> @@ -211,10 +210,6 @@ static int __init load_uefi_certs(void)
>  		kfree(dbx);
>  	}
> 
> -	/* the MOK/MOKx can not be trusted when secure boot is disabled */
> -	if (!arch_ima_get_secureboot())
> -		return 0;
> -
>  	mokx = get_cert_list(L"MokListXRT", &mok_var, &mokxsize, &status);
>  	if (!mokx) {
>  		if (status == EFI_NOT_FOUND)

The original commit message is foggy:

"
    integrity: Do not load MOK and MOKx when secure boot be disabled

    The security of Machine Owner Key (MOK) relies on secure boot. When
    secure boot is disabled, EFI firmware will not verify binary code. Then
    arbitrary efi binary code can modify MOK when rebooting.

    This patch prevents MOK/MOKx be loaded when secure boot be disabled.
"

Given that I don't understand the problem it is trying to solve:

Reviewed-by: Jarkko Sakkinen <jarkko@kernel.org>

> --
> 2.48.1
> 
> 
> Lennart
> 
> --
> Lennart Poettering, Berlin
> 

Jarkko

Re: [PATCH] Revert "integrity: Do not load MOK and MOKx when secure boot be disabled"

[lee joey]

Hi Lennart,

Lennart Poettering <mzxreary@0pointer.de> 於 2025年3月20日 週四 下午8:02寫道：
>
> This reverts commit 92ad19559ea9a8ec6f158480934ae26ebfe2c14f.
>
> This original commit this reverts creates a strange situation: it
> ensures more restrictive behaviour if SecureBoot is off then when it
> is on, which is the opposite of what one would expect.
>
> Typically, one would expect that if SB is off the validation of
> resources during the pre-kernel and kernel initialization is less
> restrictive, not more restrictive. But this check turned the world on
> its head.
>

SB off means that the chain of trust is broken. Which means that all
mechanisms rely on SB are non-secure. Meanwhile, if the integrity of kernel
can be guaranteed by other mechanism (e.g. TPM), then mok should not
be loaded when SB off.

> I'd like to ask for this commit to be reverted. If SB is on all bets are
> off regarding integrity of boot loaders and stuff, hence it makes no
> sense to be restrictive here: you cannot regain integrity once you gave
> it up once, hence if all bets are off anyway we might as well import any
> Mok keys passed to us into the kernel keyring.
>
> Or to say this differently: if an attacker got control of the pre-kernel
> boot phase they might as well patch around in the firmware apis to make
> the kernel believe it is in SB mode even if it is not. Hence the check
> carries no value. It doesn't protect anything in any effective way.
>

If this is the case, the check of MokListTrustedRT can also be removed.
All mok can directly be added to machine keyring then link with
secondary keyring.
Because attacker can create MokListTrusted/MokListTrusted variables to cheat
bootloader or kernel. The check of MokListTrustedRT is useless.

> The reason i'd like this check to go is that I'd like a nice way to
> insert keys from pre-boot into into the kernel keyring for use with
> signed dm-verity, without requiring recompilation of the kernel, and
> without SB database games. i.e. i'd like to use a regular, signed
> distro kernel, and pass to it additional keys to insert into the
> kernel keyring in a reasonable way. The mok stuff would be great for that,
> except it all falls apart once SB is off.
>
> You might wonder what signed dm-verity gives me if I have SB off. If
> we authenticate the boot phase up to Linux userspace via TPM-based PCR
> policies (i.e. measured boot) we can be sure of the boot integrity
> without having to rely on SB. But then we'd still like to use
> dm-verity based code signing for userspace.

hm... I am a bit confused. So, this patch can help the above scenario?

> ---
>  security/integrity/platform_certs/load_uefi.c | 5 -----
>  1 file changed, 5 deletions(-)
>
> diff --git a/security/integrity/platform_certs/load_uefi.c b/security/integrity/platform_certs/load_uefi.c
> index d1fdd113450a..7783bcacd26c 100644
> --- a/security/integrity/platform_certs/load_uefi.c
> +++ b/security/integrity/platform_certs/load_uefi.c
> @@ -7,7 +7,6 @@
>  #include <linux/err.h>
>  #include <linux/efi.h>
>  #include <linux/slab.h>
> -#include <linux/ima.h>
>  #include <keys/asymmetric-type.h>
>  #include <keys/system_keyring.h>
>  #include "../integrity.h"
> @@ -211,10 +210,6 @@ static int __init load_uefi_certs(void)
>                 kfree(dbx);
>         }
>
> -       /* the MOK/MOKx can not be trusted when secure boot is disabled */
> -       if (!arch_ima_get_secureboot())
> -               return 0;
> -
>         mokx = get_cert_list(L"MokListXRT", &mok_var, &mokxsize, &status);
>         if (!mokx) {
>                 if (status == EFI_NOT_FOUND)
> --
> 2.48.1

Thanks
Joey Lee

Re: [PATCH] Revert "integrity: Do not load MOK and MOKx when secure boot be disabled"

[Lennart Poettering]

On Fr, 21.03.25 15:13, lee joey (joeyli.kernel@gmail.com) wrote:

> Hi Lennart,
>
> Lennart Poettering <mzxreary@0pointer.de> 於 2025年3月20日 週四 下午8:02寫道：
> >
> > This reverts commit 92ad19559ea9a8ec6f158480934ae26ebfe2c14f.
> >
> > This original commit this reverts creates a strange situation: it
> > ensures more restrictive behaviour if SecureBoot is off then when it
> > is on, which is the opposite of what one would expect.
> >
> > Typically, one would expect that if SB is off the validation of
> > resources during the pre-kernel and kernel initialization is less
> > restrictive, not more restrictive. But this check turned the world on
> > its head.
> >
>
> SB off means that the chain of trust is broken. Which means that all
> mechanisms rely on SB are non-secure. Meanwhile, if the integrity of kernel
> can be guaranteed by other mechanism (e.g. TPM), then mok should not
> be loaded when SB off.

Why not? as you say, chain of trust is broken: the kernel itself is
not immediately integrity protected and neither is the firmware. Hence
filtering out keys in this case is really pointless.

> > I'd like to ask for this commit to be reverted. If SB is on all bets are
> > off regarding integrity of boot loaders and stuff, hence it makes no
> > sense to be restrictive here: you cannot regain integrity once you gave
> > it up once, hence if all bets are off anyway we might as well import any
> > Mok keys passed to us into the kernel keyring.
> >
> > Or to say this differently: if an attacker got control of the pre-kernel
> > boot phase they might as well patch around in the firmware apis to make
> > the kernel believe it is in SB mode even if it is not. Hence the check
> > carries no value. It doesn't protect anything in any effective way.
>
> If this is the case, the check of MokListTrustedRT can also be
> removed.

I think it makes sense to honour explicit knobs, such as
MokListTrustedRT: It has a very clear meaning: it indicates whether to
import the keys or not.

This is quite different from SB state, which is not explicit about
importing keys at all, it just indicates whether firmware level
validation of signatures is done or not.

> All mok can directly be added to machine keyring then link with
> secondary keyring.
> Because attacker can create MokListTrusted/MokListTrusted variables to cheat
> bootloader or kernel. The check of MokListTrustedRT is useless.

Yeah, it does not carry immediate security value if SB is off. But it
does allow finer-grained control by pre-boot code of how the kernel
later sets up things. Hence I'd keep it.

> > You might wonder what signed dm-verity gives me if I have SB off. If
> > we authenticate the boot phase up to Linux userspace via TPM-based PCR
> > policies (i.e. measured boot) we can be sure of the boot integrity
> > without having to rely on SB. But then we'd still like to use
> > dm-verity based code signing for userspace.
>
> hm... I am a bit confused. So, this patch can help the above
> scenario?

The revert I posted will allow us to populate the kernel keyring used
for dm-verity signature checks from pre-boot even if SB is off. Via
local or remote attestation during boot we can later validate this
chosen boot path, and hence can a-posteriori validate that everything
is OK even if the a-priori SB check is not done. But once we have
validated that we then have the key in the kernel keyring for later
dm-verity validations, which is all we wanted.

Lennart

--
Lennart Poettering, Berlin

Re: [PATCH] Revert "integrity: Do not load MOK and MOKx when secure boot be disabled"

[James Bottomley]

On Fri, 2025-03-21 at 15:13 +0800, lee joey wrote:
> Hi Lennart,
> 
> Lennart Poettering <mzxreary@0pointer.de> 於 2025年3月20日 週四 下午8:02寫道：
> > 
> > This reverts commit 92ad19559ea9a8ec6f158480934ae26ebfe2c14f.
> > 
> > This original commit this reverts creates a strange situation: it
> > ensures more restrictive behaviour if SecureBoot is off then when
> > it is on, which is the opposite of what one would expect.
> > 
> > Typically, one would expect that if SB is off the validation of
> > resources during the pre-kernel and kernel initialization is less
> > restrictive, not more restrictive. But this check turned the world
> > on its head.
> > 
> 
> SB off means that the chain of trust is broken. Which means that all
> mechanisms rely on SB are non-secure. Meanwhile, if the integrity of
> kernel can be guaranteed by other mechanism (e.g. TPM), then mok
> should not be loaded when SB off.

I think the point being made here is that there are other integrity
mechanisms than secure boot which can protect the early boot
environment.

A second argument would be that we still load the UEFI certificates
into the chain, and they have exactly the same early boot guarantees as
the MOK ones, so we're not being consistent: we should load all of them
all the time or none.  The boot envelope still has some protections
even without secure boot or anything else.

The third must be the module one: we've trained users to insert module
signing certificates into MOK.  If they find that mechanism doesn't
work under some possible circumstances they're going to be unhappy.

Part of the problem with that last is with the lockdown creep we're
increasing the chances that users will see turning off secure boot as
the solution to fixing some lockdown problems (say they want hibernate
for instance) so having the kernel be unable to load external modules
in that case when they're trying to relax protections is highly counter
intuitive.

Regards,

James

Re: [PATCH] Revert "integrity: Do not load MOK and MOKx when secure boot be disabled"

[Jarkko Sakkinen]

On Fri, Mar 21, 2025 at 09:39:55AM +0100, Lennart Poettering wrote:
> On Fr, 21.03.25 15:13, lee joey (joeyli.kernel@gmail.com) wrote:
> 
> > Hi Lennart,
> >
> > Lennart Poettering <mzxreary@0pointer.de> 於 2025年3月20日 週四 下午8:02寫道：
> > >
> > > This reverts commit 92ad19559ea9a8ec6f158480934ae26ebfe2c14f.
> > >
> > > This original commit this reverts creates a strange situation: it
> > > ensures more restrictive behaviour if SecureBoot is off then when it
> > > is on, which is the opposite of what one would expect.
> > >
> > > Typically, one would expect that if SB is off the validation of
> > > resources during the pre-kernel and kernel initialization is less
> > > restrictive, not more restrictive. But this check turned the world on
> > > its head.
> > >
> >
> > SB off means that the chain of trust is broken. Which means that all
> > mechanisms rely on SB are non-secure. Meanwhile, if the integrity of kernel
> > can be guaranteed by other mechanism (e.g. TPM), then mok should not
> > be loaded when SB off.
> 
> Why not? as you say, chain of trust is broken: the kernel itself is
> not immediately integrity protected and neither is the firmware. Hence
> filtering out keys in this case is really pointless.

The way I look at this is that unless there is an actual threat scenario
that we protect against by hiding MOK keys, then we should not hide
those keys.

Since I don't find any threat scenarios my reviewed-by holds. Pointless
checks is security by obfuscation, which is not really security.

BR, Jarkko

Re: [PATCH] Revert "integrity: Do not load MOK and MOKx when secure boot be disabled"

[Mimi Zohar]

On Thu, 2025-03-20 at 13:02 +0100, Lennart Poettering wrote:
> This reverts commit 92ad19559ea9a8ec6f158480934ae26ebfe2c14f.
> 
> This original commit this reverts creates a strange situation: it
> ensures more restrictive behaviour if SecureBoot is off then when it
> is on, which is the opposite of what one would expect.
> 
> Typically, one would expect that if SB is off the validation of
> resources during the pre-kernel and kernel initialization is less
> restrictive, not more restrictive. But this check turned the world on
> its head.

Hi Lennart,

I'm really sorry for the long delay ...

From an IMA perspective, the default is to only trust keys built into the kernel
or certificates signed by the builtin keys and loaded onto the
.secondary_trusted_keys keyring.
                                                                                
The ability of loading MOK keys onto the .machine keyring and linked to the
.secondary_trusted_keys keyring is an exception based on the assumption that
that there is a secure boot chain of trust.  Allowing untrusted keys onto or
linked to the .secondary_trusted_keys keyring, would potentially allow loading
code signing keys onto the IMA keyring signed by untrusted MOK keys.
                                                                                
I was really hesitant to allow this exception of loading MOK keys onto the
.machine keyring in the first place.  I'm now even more concerned.
                                                                                
This is not just an issue of being more or less restrictive, but of adding a new
integrity gap when one didn't exist previously.

Mimi


> 
> I'd like to ask for this commit to be reverted. If SB is on all bets are
> off regarding integrity of boot loaders and stuff, hence it makes no
> sense to be restrictive here: you cannot regain integrity once you gave
> it up once, hence if all bets are off anyway we might as well import any
> Mok keys passed to us into the kernel keyring.
> 
> Or to say this differently: if an attacker got control of the pre-kernel
> boot phase they might as well patch around in the firmware apis to make
> the kernel believe it is in SB mode even if it is not. Hence the check
> carries no value. It doesn't protect anything in any effective way.
> 
> The reason i'd like this check to go is that I'd like a nice way to
> insert keys from pre-boot into into the kernel keyring for use with
> signed dm-verity, without requiring recompilation of the kernel, and
> without SB database games. i.e. i'd like to use a regular, signed
> distro kernel, and pass to it additional keys to insert into the
> kernel keyring in a reasonable way. The mok stuff would be great for that,
> except it all falls apart once SB is off.
> 
> You might wonder what signed dm-verity gives me if I have SB off. If
> we authenticate the boot phase up to Linux userspace via TPM-based PCR
> policies (i.e. measured boot) we can be sure of the boot integrity
> without having to rely on SB. But then we'd still like to use
> dm-verity based code signing for userspace.
> ---
>  security/integrity/platform_certs/load_uefi.c | 5 -----
>  1 file changed, 5 deletions(-)
> 
> diff --git a/security/integrity/platform_certs/load_uefi.c b/security/integrity/platform_certs/load_uefi.c
> index d1fdd113450a..7783bcacd26c 100644
> --- a/security/integrity/platform_certs/load_uefi.c
> +++ b/security/integrity/platform_certs/load_uefi.c
> @@ -7,7 +7,6 @@
>  #include <linux/err.h>
>  #include <linux/efi.h>
>  #include <linux/slab.h>
> -#include <linux/ima.h>
>  #include <keys/asymmetric-type.h>
>  #include <keys/system_keyring.h>
>  #include "../integrity.h"
> @@ -211,10 +210,6 @@ static int __init load_uefi_certs(void)
>  		kfree(dbx);
>  	}
> 
> -	/* the MOK/MOKx can not be trusted when secure boot is disabled */
> -	if (!arch_ima_get_secureboot())
> -		return 0;
> -
>  	mokx = get_cert_list(L"MokListXRT", &mok_var, &mokxsize, &status);
>  	if (!mokx) {
>  		if (status == EFI_NOT_FOUND)
> --
> 2.48.1
> 
> 
> Lennart
> 
> --
> Lennart Poettering, Berlin
> 

Re: [PATCH] Revert "integrity: Do not load MOK and MOKx when secure boot be disabled"

[Lennart Poettering]

On Mi, 02.07.25 21:40, Mimi Zohar (zohar@linux.ibm.com) wrote:

> On Thu, 2025-03-20 at 13:02 +0100, Lennart Poettering wrote:
> > This reverts commit 92ad19559ea9a8ec6f158480934ae26ebfe2c14f.
> >
> > This original commit this reverts creates a strange situation: it
> > ensures more restrictive behaviour if SecureBoot is off then when it
> > is on, which is the opposite of what one would expect.
> >
> > Typically, one would expect that if SB is off the validation of
> > resources during the pre-kernel and kernel initialization is less
> > restrictive, not more restrictive. But this check turned the world on
> > its head.
>
> Hi Lennart,
>
> I'm really sorry for the long delay ...
>
> >From an IMA perspective, the default is to only trust keys built into the kernel
> or certificates signed by the builtin keys and loaded onto the
> .secondary_trusted_keys keyring.
>
> The ability of loading MOK keys onto the .machine keyring and linked to the
> .secondary_trusted_keys keyring is an exception based on the assumption that
> that there is a secure boot chain of trust.  Allowing untrusted keys onto or
> linked to the .secondary_trusted_keys keyring, would potentially allow loading
> code signing keys onto the IMA keyring signed by untrusted MOK keys.
>
> I was really hesitant to allow this exception of loading MOK keys onto the
> .machine keyring in the first place.  I'm now even more concerned.
>
> This is not just an issue of being more or less restrictive, but of adding a new
> integrity gap when one didn't exist previously.

But we are talking of the case here where SecureBoot is *off*,
i.e. there is a concious decision in place that there is no trust
chain, and that the firmware *happily* *already* accepts unsigned boot
loaders/kernels and just runs with them. If SecureBoot is already off,
then an attacker can patch around in the kernel invoked at boot
completely freely anyway, there is *no* authentication done. Hence
it's really weird to then insist that the path into the kernel keyring
via mok keys is off in *only* this case, because an attacker can get
into that anyway in this case, it's just a lot more cumbersome.

It's really strange that currently when people ask for tight security
(i.e. SB on) the linux kernel is super relaxed and allows any keys to
be inserted, but if people ask for security checks to be off (i.e. SB
off) the kernel starts being super strict and doesn't allow any keys
to propagate into mok. That's really confusing and contradictory, no?

Lennart

--
Lennart Poettering, Berlin

Re: [PATCH] Revert "integrity: Do not load MOK and MOKx when secure boot be disabled"

[Mimi Zohar]

On Thu, 2025-07-03 at 09:18 +0200, Lennart Poettering wrote:
> On Mi, 02.07.25 21:40, Mimi Zohar (zohar@linux.ibm.com) wrote:
> 
> > On Thu, 2025-03-20 at 13:02 +0100, Lennart Poettering wrote:
> > > This reverts commit 92ad19559ea9a8ec6f158480934ae26ebfe2c14f.
> > > 
> > > This original commit this reverts creates a strange situation: it
> > > ensures more restrictive behaviour if SecureBoot is off then when it
> > > is on, which is the opposite of what one would expect.
> > > 
> > > Typically, one would expect that if SB is off the validation of
> > > resources during the pre-kernel and kernel initialization is less
> > > restrictive, not more restrictive. But this check turned the world on
> > > its head.
> > 
> > Hi Lennart,
> > 
> > I'm really sorry for the long delay ...
> > 
> > > From an IMA perspective, the default is to only trust keys built into the kernel
> > or certificates signed by the builtin keys and loaded onto the
> > .secondary_trusted_keys keyring.
> > 
> > The ability of loading MOK keys onto the .machine keyring and linked to the
> > .secondary_trusted_keys keyring is an exception based on the assumption that
> > that there is a secure boot chain of trust.  Allowing untrusted keys onto or
> > linked to the .secondary_trusted_keys keyring, would potentially allow loading
> > code signing keys onto the IMA keyring signed by untrusted MOK keys.
> > 
> > I was really hesitant to allow this exception of loading MOK keys onto the
> > .machine keyring in the first place.  I'm now even more concerned.
> > 
> > This is not just an issue of being more or less restrictive, but of adding a new
> > integrity gap when one didn't exist previously.
> 
> But we are talking of the case here where SecureBoot is *off*,

Exactly, so there is no trust in any keys other than those built into the
kernel. True that is of course dependent on trusting the kernel.  In the case of
MOK, trusting additional keys requires at minimum a "safe" secure boot
environment and other things to prevent its abuse.

> i.e. there is a concious decision in place that there is no trust
> chain, and that the firmware *happily* *already* accepts unsigned boot
> loaders/kernels and just runs with them. If SecureBoot is already off,
> then an attacker can patch around in the kernel invoked at boot
> completely freely anyway, there is *no* authentication done. Hence
> it's really weird to then insist that the path into the kernel keyring
> via mok keys is off in *only* this case, because an attacker can get
> into that anyway in this case, it's just a lot more cumbersome.
> 
> It's really strange that currently when people ask for tight security
> (i.e. SB on) the linux kernel is super relaxed and allows any keys to
> be inserted, but if people ask for security checks to be off (i.e. SB
> off) the kernel starts being super strict and doesn't allow any keys
> to propagate into mok. That's really confusing and contradictory, no?

That all may be true, but you're ignoring what I said about only "trusting" MOK
in certain situations.  If you have another safer, better mechanism for
establishing a new root of trust for keys (e.g. TPM), then by all means share it
and we can make additional exceptions.

Mimi

Re: [PATCH] Revert "integrity: Do not load MOK and MOKx when secure boot be disabled"

[Lennart Poettering]

On Do, 03.07.25 07:23, Mimi Zohar (zohar@linux.ibm.com) wrote:

> > > The ability of loading MOK keys onto the .machine keyring and linked to the
> > > .secondary_trusted_keys keyring is an exception based on the assumption that
> > > that there is a secure boot chain of trust.  Allowing untrusted keys onto or
> > > linked to the .secondary_trusted_keys keyring, would potentially allow loading
> > > code signing keys onto the IMA keyring signed by untrusted MOK keys.
> > >
> > > I was really hesitant to allow this exception of loading MOK keys onto the
> > > .machine keyring in the first place.  I'm now even more concerned.
> > >
> > > This is not just an issue of being more or less restrictive, but of adding a new
> > > integrity gap when one didn't exist previously.
> >
> > But we are talking of the case here where SecureBoot is *off*,
>
> Exactly, so there is no trust in any keys other than those built into the
> kernel.

No! There *is* *no *trust* in this case where SB is off, not in those
keys built into the kernel nor in any other. Believing there was is
just a really broken security model!

> True that is of course dependent on trusting the kernel.  In the case of
> MOK, trusting additional keys requires at minimum a "safe" secure boot
> environment and other things to prevent its abuse.

The thing is that if SB is off, then all bets are off, it's really
pointless in assuming the kernel image had any trust left you'd need
to protect. That's just *not* the case. Where do you think that trust
should come from?

If SB is off, then anything that got loaded early enough could just
patch arbitrary keys into the ELF image of the kernel before starting
it, and everything will look perfect later on, because the image is
not authenticated after all via SB. So there *already* is a way into
the kernel keyring with this – it's just really messy to parse and
patch ELF at runtime like this from the bootloader. My hope with just
relaxing the rules on MOK keys when SB is off is to just make this
stuff cleaner and more elegant (and also to leave the ELF image intact
so that we get clean measurements, both of the kernel and of the keys
we add).

> > i.e. there is a concious decision in place that there is no trust
> > chain, and that the firmware *happily* *already* accepts unsigned boot
> > loaders/kernels and just runs with them. If SecureBoot is already off,
> > then an attacker can patch around in the kernel invoked at boot
> > completely freely anyway, there is *no* authentication done. Hence
> > it's really weird to then insist that the path into the kernel keyring
> > via mok keys is off in *only* this case, because an attacker can get
> > into that anyway in this case, it's just a lot more cumbersome.
> >
> > It's really strange that currently when people ask for tight security
> > (i.e. SB on) the linux kernel is super relaxed and allows any keys to
> > be inserted, but if people ask for security checks to be off (i.e. SB
> > off) the kernel starts being super strict and doesn't allow any keys
> > to propagate into mok. That's really confusing and contradictory, no?
>
> That all may be true, but you're ignoring what I said about only "trusting" MOK
> in certain situations.  If you have another safer, better mechanism for
> establishing a new root of trust for keys (e.g. TPM), then by all means share it
> and we can make additional exceptions.

Yes, we have that in systemd: there's local attestation in place
already in systemd via the "systemd-pcrlock" feature. i.e. the idea is
that the disk encryption keys are only released to the OS if the
measurements of the boot phase match some golden measurements. This is
in a way a reasonable alternative (or addition) to SecureBoot: instead of
prohibiting code to run if it doesn't carry a signature of some
trusted key, you let it all run, but then later on you refuse to give
it the disk encryptions keys – the keys to the kingdom – unless the
measurements all along the way match what you expect them to be. This
protects the OS quite nicely, and makes SB to some level optional, as
we basically enforce security "a-posteriori" rather than "a-priori" – by
means of the TPM's key policies.

Now you might wonder: if we have such local attestation policies, why
do we *also* want to get keys into the kernel keyring? That's because
the attestation policies are checked (primarily) when FDE is unlocked,
so that's our security boundary, our milestone where eveything
*before* is protected via attestation, but which cannot protect
anything *after*. In my model we then want to protect
any further resources via the kernel keyring then. hence it matters to
us to have a clean, elegant way, to insert keys *before* that
milestone that then can protect resources comeing *after* it.

Why do I want to avoid SB at all for these setups? Mostly, because
it's a bureacractic effort to get your keys intot he Microsoft
keyring, and if you do get them there, then their security value is
kinda weak anyway, because the allowlist that the keyring is is such
an extremely wide net, it's at best a denylist of bad stuff rather
than an allowlist of good stuff at this point. It's kinda undemocratic
too. But anyway, the pros and cons of SB are another discussion. I am
primarily interested in making it optional, so that you can get
security with SB and without SB, because you always have someting to
protect the boot, and always something that protects the rest.

Lennart

--
Lennart Poettering, Berlin

Re: [PATCH] Revert "integrity: Do not load MOK and MOKx when secure boot be disabled"

[Mimi Zohar]

On Thu, 2025-07-03 at 15:04 +0200, Lennart Poettering wrote:
[ ... ]
> The thing is that if SB is off, then all bets are off, it's really
> pointless in assuming the kernel image had any trust left you'd need
> to protect. That's just *not* the case. Where do you think that trust
> should come from?
> 
> If SB is off, then anything that got loaded early enough could just
> patch arbitrary keys into the ELF image of the kernel before starting
> it, and everything will look perfect later on, because the image is
> not authenticated after all via SB. So there *already* is a way into
> the kernel keyring with this – it's just really messy to parse and
> patch ELF at runtime like this from the bootloader. My hope with just
> relaxing the rules on MOK keys when SB is off is to just make this
> stuff cleaner and more elegant (and also to leave the ELF image intact
> so that we get clean measurements, both of the kernel and of the keys
> we add).
> 
> > > i.e. there is a concious decision in place that there is no trust
> > > chain, and that the firmware *happily* *already* accepts unsigned boot
> > > loaders/kernels and just runs with them. If SecureBoot is already off,
> > > then an attacker can patch around in the kernel invoked at boot
> > > completely freely anyway, there is *no* authentication done. Hence
> > > it's really weird to then insist that the path into the kernel keyring
> > > via mok keys is off in *only* this case, because an attacker can get
> > > into that anyway in this case, it's just a lot more cumbersome.
> > > 
> > > It's really strange that currently when people ask for tight security
> > > (i.e. SB on) the linux kernel is super relaxed and allows any keys to
> > > be inserted, but if people ask for security checks to be off (i.e. SB
> > > off) the kernel starts being super strict and doesn't allow any keys
> > > to propagate into mok. That's really confusing and contradictory, no?
> > 
> > That all may be true, but you're ignoring what I said about only "trusting" MOK
> > in certain situations.  If you have another safer, better mechanism for
> > establishing a new root of trust for keys (e.g. TPM), then by all means share it
> > and we can make additional exceptions.
> 
> Yes, we have that in systemd: there's local attestation in place
> already in systemd via the "systemd-pcrlock" feature. i.e. the idea is
> that the disk encryption keys are only released to the OS if the
> measurements of the boot phase match some golden measurements. This is
> in a way a reasonable alternative (or addition) to SecureBoot: instead of
> prohibiting code to run if it doesn't carry a signature of some
> trusted key, you let it all run, but then later on you refuse to give
> it the disk encryptions keys – the keys to the kingdom – unless the
> measurements all along the way match what you expect them to be. This
> protects the OS quite nicely, and makes SB to some level optional, as
> we basically enforce security "a-posteriori" rather than "a-priori" – by
> means of the TPM's key policies.
> 
> Now you might wonder: if we have such local attestation policies, why
> do we *also* want to get keys into the kernel keyring? That's because
> the attestation policies are checked (primarily) when FDE is unlocked,
> so that's our security boundary, our milestone where eveything
> *before* is protected via attestation, but which cannot protect
> anything *after*. In my model we then want to protect
> any further resources via the kernel keyring then. hence it matters to
> us to have a clean, elegant way, to insert keys *before* that
> milestone that then can protect resources comeing *after* it.
> 
> Why do I want to avoid SB at all for these setups? Mostly, because
> it's a bureacractic effort to get your keys intot he Microsoft
> keyring, and if you do get them there, then their security value is
> kinda weak anyway, because the allowlist that the keyring is is such
> an extremely wide net, it's at best a denylist of bad stuff rather
> than an allowlist of good stuff at this point. It's kinda undemocratic
> too. But anyway, the pros and cons of SB are another discussion. I am
> primarily interested in making it optional, so that you can get
> security with SB and without SB, because you always have someting to
> protect the boot, and always something that protects the rest.

You're basically relying on trusted/verified boot and, in TPM 1.2 terminology,
sealing a key to a TPM PCR value.  Only if the PCR matches an expected value is
the key released.  Instead of relying on MOK, the keys could be stored in the
TPM NVRAM and loaded onto the existing .machine keyring or define a new keyring
linked to the .secondary_trusted_keys keyring[1].  Then you could really claim
the TPM as a new root of trust for both trusted and secure boot without any
dependency on MOK.
                                                                                
That would be preferable to changing the existing expectations to loading the
MOK keys when secure boot is not enabled.        
                                                                                
[1] A prior attempt to load keys from TPM NVRAM.                               
https://lore.kernel.org/linux-integrity/20210225203229.363302-1-patrick@puiterwijk.org/

Mimi

Re: [PATCH] Revert "integrity: Do not load MOK and MOKx when secure boot be disabled"

[GONG Ruiqi]

On 7/3/2025 9:04 PM, Lennart Poettering wrote:
> On Do, 03.07.25 07:23, Mimi Zohar (zohar@linux.ibm.com) wrote:
> 
>>>> The ability of loading MOK keys onto the .machine keyring and linked to the
>>>> .secondary_trusted_keys keyring is an exception based on the assumption that
>>>> that there is a secure boot chain of trust.  Allowing untrusted keys onto or
>>>> linked to the .secondary_trusted_keys keyring, would potentially allow loading
>>>> code signing keys onto the IMA keyring signed by untrusted MOK keys.
>>>>
>>>> I was really hesitant to allow this exception of loading MOK keys onto the
>>>> .machine keyring in the first place.  I'm now even more concerned.
>>>>
>>>> This is not just an issue of being more or less restrictive, but of adding a new
>>>> integrity gap when one didn't exist previously.
>>>
>>> But we are talking of the case here where SecureBoot is *off*,
>>
>> Exactly, so there is no trust in any keys other than those built into the
>> kernel.
> 
> No! There *is* *no *trust* in this case where SB is off, not in those
> keys built into the kernel nor in any other. Believing there was is
> just a really broken security model!
> 
>> True that is of course dependent on trusting the kernel.  In the case of
>> MOK, trusting additional keys requires at minimum a "safe" secure boot
>> environment and other things to prevent its abuse.
> 
> The thing is that if SB is off, then all bets are off, it's really
> pointless in assuming the kernel image had any trust left you'd need
> to protect. That's just *not* the case. Where do you think that trust
> should come from?
> 
> If SB is off, then anything that got loaded early enough could just
> patch arbitrary keys into the ELF image of the kernel before starting
> it, and everything will look perfect later on, because the image is
> not authenticated after all via SB. So there *already* is a way into
> the kernel keyring with this – it's just really messy to parse and
> patch ELF at runtime like this from the bootloader. My hope with just
> relaxing the rules on MOK keys when SB is off is to just make this
> stuff cleaner and more elegant (and also to leave the ELF image intact
> so that we get clean measurements, both of the kernel and of the keys
> we add).

Just curious: if an attacker takes control of the boot phase earlier
than the kernel, then not just this check has no value, but any check in
the kernel has no value, right? Anything that got loaded early enough
could theoretically patch the kernel with anything on anywhere. So shall
we just remove them all?

Certainly the answer is no, and they are still meaningful somehow and
somewhere. IMHO I think the concern behind the check is reasonable, but
the actual code could be an overkill. It would be better if it does:

  if (arch_ima_get_secureboot() && ima_mok_verify()) // hypothetical

, and in the future we could extend the ima policy for the boot phase
chain of trust and perform the check here accordingly, i.e. let the
users decide how things should go.

While for the current situation, my personal advice would be to add a
config to control whether or not the check is conducted. Let's call it
CONFIG_LOAD_UEFI_KEYS_STRICT temporarily:

#ifdef CONFIG_LOAD_UEFI_KEYS_STRICT
  /* the MOK/MOKx can not be trusted when secure boot is disabled */
  if (!arch_ima_get_secureboot())
          return 0;
#endif

so that both sides are happy, and we can think of more fine-grained
verification methods, like the one I said above, for the strict mode
afterwards.

-Ruiqi

> 
>>> i.e. there is a concious decision in place that there is no trust
>>> chain, and that the firmware *happily* *already* accepts unsigned boot
>>> loaders/kernels and just runs with them. If SecureBoot is already off,
>>> then an attacker can patch around in the kernel invoked at boot
>>> completely freely anyway, there is *no* authentication done. Hence
>>> it's really weird to then insist that the path into the kernel keyring
>>> via mok keys is off in *only* this case, because an attacker can get
>>> into that anyway in this case, it's just a lot more cumbersome.
>>>
>>> It's really strange that currently when people ask for tight security
>>> (i.e. SB on) the linux kernel is super relaxed and allows any keys to
>>> be inserted, but if people ask for security checks to be off (i.e. SB
>>> off) the kernel starts being super strict and doesn't allow any keys
>>> to propagate into mok. That's really confusing and contradictory, no?
>>
>> That all may be true, but you're ignoring what I said about only "trusting" MOK
>> in certain situations.  If you have another safer, better mechanism for
>> establishing a new root of trust for keys (e.g. TPM), then by all means share it
>> and we can make additional exceptions.
> 
> Yes, we have that in systemd: there's local attestation in place
> already in systemd via the "systemd-pcrlock" feature. i.e. the idea is
> that the disk encryption keys are only released to the OS if the
> measurements of the boot phase match some golden measurements. This is
> in a way a reasonable alternative (or addition) to SecureBoot: instead of
> prohibiting code to run if it doesn't carry a signature of some
> trusted key, you let it all run, but then later on you refuse to give
> it the disk encryptions keys – the keys to the kingdom – unless the
> measurements all along the way match what you expect them to be. This
> protects the OS quite nicely, and makes SB to some level optional, as
> we basically enforce security "a-posteriori" rather than "a-priori" – by
> means of the TPM's key policies.
> 
> Now you might wonder: if we have such local attestation policies, why
> do we *also* want to get keys into the kernel keyring? That's because
> the attestation policies are checked (primarily) when FDE is unlocked,
> so that's our security boundary, our milestone where eveything
> *before* is protected via attestation, but which cannot protect
> anything *after*. In my model we then want to protect
> any further resources via the kernel keyring then. hence it matters to
> us to have a clean, elegant way, to insert keys *before* that
> milestone that then can protect resources comeing *after* it.
> 
> Why do I want to avoid SB at all for these setups? Mostly, because
> it's a bureacractic effort to get your keys intot he Microsoft
> keyring, and if you do get them there, then their security value is
> kinda weak anyway, because the allowlist that the keyring is is such
> an extremely wide net, it's at best a denylist of bad stuff rather
> than an allowlist of good stuff at this point. It's kinda undemocratic
> too. But anyway, the pros and cons of SB are another discussion. I am
> primarily interested in making it optional, so that you can get
> security with SB and without SB, because you always have someting to
> protect the boot, and always something that protects the rest.
> 
> Lennart
> 
> --
> Lennart Poettering, Berlin
> 

Re: [PATCH] Revert "integrity: Do not load MOK and MOKx when secure boot be disabled"

[Lennart Poettering]

On Do, 03.07.25 19:56, Mimi Zohar (zohar@linux.ibm.com) wrote:

> > Yes, we have that in systemd: there's local attestation in place
> > already in systemd via the "systemd-pcrlock" feature. i.e. the idea is
> > that the disk encryption keys are only released to the OS if the
> > measurements of the boot phase match some golden measurements. This is
> > in a way a reasonable alternative (or addition) to SecureBoot: instead of
> > prohibiting code to run if it doesn't carry a signature of some
> > trusted key, you let it all run, but then later on you refuse to give
> > it the disk encryptions keys – the keys to the kingdom – unless the
> > measurements all along the way match what you expect them to be. This
> > protects the OS quite nicely, and makes SB to some level optional, as
> > we basically enforce security "a-posteriori" rather than "a-priori" – by
> > means of the TPM's key policies.
> >
> > Now you might wonder: if we have such local attestation policies, why
> > do we *also* want to get keys into the kernel keyring? That's because
> > the attestation policies are checked (primarily) when FDE is unlocked,
> > so that's our security boundary, our milestone where eveything
> > *before* is protected via attestation, but which cannot protect
> > anything *after*. In my model we then want to protect
> > any further resources via the kernel keyring then. hence it matters to
> > us to have a clean, elegant way, to insert keys *before* that
> > milestone that then can protect resources comeing *after* it.
> >
> > Why do I want to avoid SB at all for these setups? Mostly, because
> > it's a bureacractic effort to get your keys intot he Microsoft
> > keyring, and if you do get them there, then their security value is
> > kinda weak anyway, because the allowlist that the keyring is is such
> > an extremely wide net, it's at best a denylist of bad stuff rather
> > than an allowlist of good stuff at this point. It's kinda undemocratic
> > too. But anyway, the pros and cons of SB are another discussion. I am
> > primarily interested in making it optional, so that you can get
> > security with SB and without SB, because you always have someting to
> > protect the boot, and always something that protects the rest.
>
> You're basically relying on trusted/verified boot and, in TPM 1.2 terminology,
> sealing a key to a TPM PCR value.  Only if the PCR matches an expected value is
> the key released.  Instead of relying on MOK, the keys could be stored in the
> TPM NVRAM and loaded onto the existing .machine keyring or define a new keyring
> linked to the .secondary_trusted_keys keyring[1].  Then you could really claim
> the TPM as a new root of trust for both trusted and secure boot without any
> dependency on MOK.

Hmm, why involve the TPM in kernel keyring population though, if all
keys in question are vendor keys used to sign OS resources, i.e. not
local keys? It's entirely fine to ship these keys along with UKIs or
boot loaders, and in the model where SB is off they are protected by
the measurements that are done of both boot loaders and UKIs.

And what would even install the keys into the TPM in the first place?

Also note, that while a TPM can store keys, the way it is designed is
that you actually store keys outside of it, but wrap them with the
SRK that is the one you do store on the TPM. This in particular
matters as people might want to boot kernels of multiple vendors at
different times on the same system, and hence the keys for that should
not be sticky in the TPM.

Sorry, but storing keys in the TPM for this is just wrong for my
usecase.

> That would be preferable to changing the existing expectations to loading the
> MOK keys when secure boot is not enabled.

Sorry, but I vehemently disagree, that's a really broken security
model. SecureBoot on should mean strict rules and, SB off should mean
relaxed rules, and you are doing it in the opposite way.

> [1] A prior attempt to load keys from TPM NVRAM.
> https://lore.kernel.org/linux-integrity/20210225203229.363302-1-patrick@puiterwijk.org/

This seems really strange to me, as no policy is enforced on the
nvindex? The TPM is not a magic device that sprinkles "trust" magic
dust on things: you have to define your objects with a policy that
locks down access based on attestation, pins or other stuff, and it's
just not obvious what that should be here for such a kernel keyring.

Sorry, but this all seems backwards to me: what you propose weakens
the current model afaics, and you insist to be strict in the case where
an explicit request has been made to relax things by turning off SB.

Lennart

--
Lennart Poettering, Berlin

Re: [PATCH] Revert "integrity: Do not load MOK and MOKx when secure boot be disabled"

[Lennart Poettering]

On Fr, 04.07.25 09:30, GONG Ruiqi (gongruiqi1@huawei.com) wrote:

> > patch arbitrary keys into the ELF image of the kernel before starting
> > it, and everything will look perfect later on, because the image is
> > not authenticated after all via SB. So there *already* is a way into
> > the kernel keyring with this – it's just really messy to parse and
> > patch ELF at runtime like this from the bootloader. My hope with just
> > relaxing the rules on MOK keys when SB is off is to just make this
> > stuff cleaner and more elegant (and also to leave the ELF image intact
> > so that we get clean measurements, both of the kernel and of the keys
> > we add).
>
> Just curious: if an attacker takes control of the boot phase earlier
> than the kernel, then not just this check has no value, but any check in
> the kernel has no value, right? Anything that got loaded early enough
> could theoretically patch the kernel with anything on anywhere. So shall
> we just remove them all?

Measured boot protects you against that, as I explained: what we do in
our model is lock the full disk encryption to a key in the TPM that
enforces an local attestation policy: only if a all measurements match
that policy the FDE key is released to the OS. Hence yes, if SB is off
*any* code can run, but if it's not the right code then it cannot
unlock the disk. If it *is* able to unlock the FDE however, then this
is proof that the boot chain is in order, and hence the kernel can be
trusted, and it makes sense for it to defend itself from later steps.

> Certainly the answer is no, and they are still meaningful somehow and
> somewhere. IMHO I think the concern behind the check is reasonable, but
> the actual code could be an overkill. It would be better if it does:
>
>   if (arch_ima_get_secureboot() && ima_mok_verify()) // hypothetical
>
> , and in the future we could extend the ima policy for the boot phase
> chain of trust and perform the check here accordingly, i.e. let the
> users decide how things should go.
>
> While for the current situation, my personal advice would be to add a
> config to control whether or not the check is conducted. Let's call it
> CONFIG_LOAD_UEFI_KEYS_STRICT temporarily:
>
> #ifdef CONFIG_LOAD_UEFI_KEYS_STRICT
>   /* the MOK/MOKx can not be trusted when secure boot is disabled */
>   if (!arch_ima_get_secureboot())
>           return 0;
> #endif
>
> so that both sides are happy, and we can think of more fine-grained
> verification methods, like the one I said above, for the strict mode
> afterwards.

Having an option for this would be better than nothing of course, but
I seriously wonder what the value of the check is supposed to be at
all. SecureBoot=off tells the system: hey, please accept any boot-time
resource without validation, and firmware and boot loaders honour that,
but Linux then does the opposite, invents some artificial checks not
even done if SB is on!

I mean, a boot trust chain means: trust what comes before, and
authenticate/measure what comes next before you pass control to it.

But for some reason Linux makes up a different model, where if told to
not authenticate it suddenly doesn't trust half of what comes before
anymore, but the other half it does. And that's just bogus, and
illogical.

Lennart

--
Lennart Poettering, Berlin

Re: [PATCH] Revert "integrity: Do not load MOK and MOKx when secure boot be disabled"

[Mimi Zohar]

On Fri, 2025-07-04 at 09:34 +0200, Lennart Poettering wrote:
> > That would be preferable to changing the existing expectations to loading the
> > MOK keys when secure boot is not enabled.
> 
> Sorry, but I vehemently disagree, that's a really broken security
> model. SecureBoot on should mean strict rules and, SB off should mean
> relaxed rules, and you are doing it in the opposite way.

We're going around and around in circles, each of us saying the same thing over
and over.  Let's try breaking this down.

For now let's assume there are just two security models, the hybrid security
model of trusted boot transitioning to secure boot and the secure boot only
model.

In the hybrid security model of trusted boot transitioning to secure boot,
you're claiming it is always safe to load vendor keys and/or "local keys",
whether secure boot is enabled or disabled.   This makes sense, because the keys
will be measured and the disk encryption key won't be unsealed (TPM 1.2
terminology) if there are unknown keys.

I'm claiming in the secure boot ONLY model, the default is to use the set of
known builtin trusted keys and to make an exception to allow "vendor keys"
and/or "local keys" IFF secure boot is enabled.  This is a reasonable exception,
relaxing of rules.

With your understanding of "SecureBoot on should mean strict rules and, SB off
should mean relaxed rules ... " there would be no difference if Secure Boot is
enabled or disabled.  For your hybrid security model case this works
perfectly. In the secure boot only case, however, it breaks the existing
security model expectations.

The question is how can both of these security models co-exist?

Mimi