Untrusted components contained in a Trusted/Signed UKI fail to load with shim 16

[jsetje]

Due to calling back into the loader protocol every object that's loaded ends up going through a verification. A UKI that's signed with a trusted key is loaded, but any object it contains, for example a kernel, is then validated again individually. Strictly speaking this verification is not required and will in fact result in measuring the kernel twice.

This is an issue for anyone that's building a UKI and then enrolling it in a trust differs from the contained components. Whether that's a kernel signed with a key that's not trusted in the context that the UKI is loaded in or simply an unsigned kernel.

Even just measuring the kernel twice will mean measurements for those components will change just by updating to shim 16, which is not desirable either.

Please consider if this impacts you before getting a shim 16 signed.

@ardbiesheuvel suggested we fix this by adding hashes of validated sections of a UKI to the db and then check objects that are subsequently loaded against that.

@kukrimate has prototyped a fix here: #740

[kraxel]

I think @ardbiesheuvel idea is to add the authenticode hash to MokListRT instead of maintaining a separate list (as implemented by #740). Not fully sure what side effects that would have on measurements though.

[ardbiesheuvel]

I think @ardbiesheuvel idea is to add the authenticode hash to MokListRT instead of maintaining a separate list (as implemented by #740). Not fully sure what side effects that would have on measurements though.

That is what I suggested on the thread, and actually, what Jan is quoting here is more @vathpela's suggestion rather than mine.

What I suggested before is adding a PE section to an image carrying an ephemeral extension of "db", which would be used in subsequent authentications. This proposal is basically a simplification of that approach, implemented in a way that preserves compatibility when upgrading to shim 16

[bluca]

In case the implementation adds the hash to MokListRT, is the content of MokListRT measured in a PCR?

[kukrimate]

I don't think adding it to any existing allowlist without special flagging is enough, if compatibility is the goal.

To not break comaptibility we need to avoid any extra measurements.

[jsetje]

Is the extra measurement actually wrong though?

• the system loaded some UKI.
• the system loaded and booted a specific kernel in that UKI.

Not that I love breaking compatibility.

[bluca]

Yeah we'd really prefer to avoid it, the UKI spec only allows a single kernel, so there's never a doubt as to what gets booted

[kraxel]

Yeah we'd really prefer to avoid it, the UKI spec only allows a single kernel, so there's never a doubt as to what gets booted

Is that still true with the profiles added recently? They are meant to allow multiple command lines and such, but do they explicitly outlaw multiple kernels?

[bluca]

Yes, even with profiles, this is documented explicitly:

Each profile would then use the same ".linux" and ".initrd" sections, but would have a separate ".cmdline" section.

https://www.freedesktop.org/software/systemd/man/latest/systemd-stub.html#Multi-Profile%20UKIs