Allow op=POLICY to influence IPE policy loading

[RaitoBezarius]

Currently, IPE policy loading requires a PKCS#7 signature coherent with (secondary) kernel keyrings.

The usage of signature is an adoption blocker for IPE in our remote attestation usecases because having a proper PKI would induce unreproducible kernels and we would need to design mechanisms to isolate the signature bits from the kernel during the steps that lead to PCR measurements. Alternatively, we would need bootables to be allowed to load things into the kernel keyring from a UKI so that we could cleanly isolate this (and manage a PKI).

Compared to my proposal in #7, I wonder if — instead —, we could make use of the boot policy to have something that is similar akin to:

policy_name=AllowInitramfs policy_version=0.0.0
DEFAULT action=DENY

op=EXECUTE boot_verified=TRUE action=ALLOW
op=POLICY boot_verified=TRUE action=ALLOW

Then, the initramfs will load a new policy akin to this:

policy_name=Lockdown policy_version=0.0.0
DEFAULT action=DENY

op=EXECUTE dmverity_roothash=sha256:cd2c5bae7c6c579edaae4353049d58eb5f2e8be0244bf05345bc8e5ed257baff action=ALLOW

where the hash is taken by the initramfs code tailored to the user workload.

After switch root, we instruct the kernel to activate the new policy and disable the previous one, entering into the desired state of affairs.

For this to be possible, we need the securityfs IPE nodes to use themselves IPE policies in order to make IPE verify the loading of new IPE policies without the PKCS#7 constraint.

I don't think this weaken the security model of IPE, the default usecase remains "you provide signed things", IPE self-checks IPE which seems to be a reasonable if we assume that the previous IPE policy is trusted (boot policy OR a PKCS#7 one).

Alternative idea: allow IPE to add new certificates in the keyring which enable accomplishing the above by creating ephemeral PKCS#7 keys in the initramfs (I'd prefer to avoid this because it seems useless).

If this idea makes sense, I can work towards a patch.

[jxwufan]

Thanks for the write-up. Just to clarify, IPE policy signing isn't limited to the secondary keyring. We also support the platform keyring, so users can control MOK to load certificates for signing policies.

That said, I think both directions you mentioned have merit. On our end, we've actually been considering adding an op=POLICY (or similar policy load operation) to IPE, though our thinking has leaned more toward controlling which specific certificates are allowed to sign policies.

Loading policies directly from the initramfs is worth considering, but the specifics need careful thought. Reading policy text from userspace without cryptographic verification opens up risks, for example the content that gets checked may not be the same content that ultimately gets loaded. So we'd still prefer IPE to perform its own signature verification on policies.

I'm also curious about the keyring-based alternative you mentioned at the end. On first impression, a design centered around controlling the keyring directly seems like it could be a better fit.

I'd suggest sending an RFC to the mailing list so we can discuss the details there. That way the keyring subsystem folks can weigh in as well.