shim should stop loading binaries without a .sbat section

[jsetje]

Currently shim will not directly, but through the shim_lock protocol, allow binaries that do not have a .sbat section to be loaded. For shims that carry certificates for complex products such as Linux distributions, this allows various chains to be constructed and may require a carefully considered vendor_dbx to be tracked and built into shim. In particular reviewing the fact that this list is complete is essentially impossible for someone outside of the organization that has created these signed binary artifacts.

The current behavior exists because Linux kernels, which are loaded by GRUB2 and validated via shim_lock protocol are currently not labelled with a .sbat section. While it is not hard to create such a section, what exactly should result in bumping the security generation number depends a bit on the posture that a particular chain of trust subscribes to. At the bare minimum, anyone using a signed shim needs to protect boot services state, so any bypasses in the EFI stub need to be covered. At the other end of the spectrum someone, that is extremely concerned about integrity, may want to be able to revoke for any unauthorized kernel memory write issues. In order to separate this issue which is intended to discuss the mechanism for making a .sbat section mandatory for at least some chains of trust from the security generation discussion I have created a separate issue https://github.com/rhboot/shim/issues/590

Unless some external event forces an epoch upon us, it is desirable not to create one and this allow for backwards compatibility. The most obvious way to do this is to introduce a new key ring that creates a chain of trust that enforces having a .sbat section even in shim_lock protocol. Shims signed with the UEFI CA would initially be allowed to carry certificates on both key rings, but would would eventually be required to only embed keys that trust binaries that are required to have a .sbat section. However, this would not prevent someone from building and signing a shim with certificates on the key ring that does not require a .sbat section which means that folks building small or even one-off trusts do not need to worry about curating the SBAT security generation for their kernels.

[jsetje]

@jejb from some external discussions it sounded like you might be using shim to produce binaries that implement a slightly different posture. Would what is outlined above be workable in the scenarios you care about? If not, I would really appreciate any comments.

[jejb]

On Wed, 2023-08-02 at 13:35 -0700, Jan Setje-Eilers wrote:

@jejb  from some external discussions it sounded like you might be using shim to produce binaries that implement a slightly different posture. Would what is outlined above be workable in the scenarios you care about? If not, I would really appreciate any comments.

Well, no, not loading binaries without an sbat section would leave us without any default option for the kernel. Peter told me there was no plan to do this. I don't think he said it in the public thread, but I did refer to it:

@.***/

There are two reasons for this: Firstly making a kernel default boot just work for people who run a secure boot chain, and secondly for running EFI binaries (like machine test and firmware upgrade) from the grub command line.

I really think that if this functionality were to become mandatory we'd need both some indication of UEFI support for it and a revocation mechanism that's better than shim delivers the updates.

James

[jsetje]

Thank you for taking a look at this!

Loading system specific binaries from the GRUB menu is an interesting use case. Presumably those would be signed by either the PK or another key on the system's DB and not by a key embedded in shim. That's a good argument for making a keyring that requires binaries to carry a .sbat section to remain special in that way.

[ValdikSS]

In fact, loading unsigned files without .sbat secrion entolled by hash does not work: https://github.com/rhboot/shim/issues/489