[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 at 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