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