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