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@xxxxxxxxxxxxx) 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