SBAT revocation metadata updates without re-issuing a new shim binary

[jsetje]

The current model for delivering SBAT security generation requirements relies on issuing an updated shim binary. There really is no reason that this metadata can't be included in another signed binary.

I have some code that will pull another set of levels from a section in a certmule binary, but that raises the question if such revocations should come only from a specifically named file, or if shim should check every binary it loads for updated revocation metadata.

Delivering updated revocations in GRUB may be convenient for distros.

We probably don't want to end up with dozens of certmule binaries that all need to be evaluated in order though.

[jsetje]

I tried implementing a pass that checks to see if a set of revocations will lead to a self-revocation of the currently running bits and while that isn't completely open ended, for an large set of chained binaries, it's more complexity than I want to introduce at this level. The most sane thing is probably to limit the processing of revocation sections to either a specific single binary or small set of binaries.

[vbrahmajosyula1]

Hello Jan,

I work for Photon OS, VMware/Broadcom. We are in the process of submitting a new shim-review for 15.7.
I had a question on possible different methods in which revocation data can be delivered and came across this ticket.

The summary of the ticket mentions that an updated shim with new SBAT is the only available method.

1. Has anything changed since the ticket creation?
2. Is an alternate method like firmware update/dbx update or others in discussion to update/reset SBAT generation?

Thanks in advance.

[mikebeaton]

Hi.

Previous to SBAT, any other loader (not grub+shim) can apply up-to-date security by applying up-to-date dbx etc. from firmware storage (which just amounts to using platform image loader with SB enabled).

However, with SBAT, any loader which wants to load Linux without grub (e.g. we have one here) has a problem, because some of the up-to-date information about what to accept and revoke is stored in the SBAT data in shim. We have a working work-around for this, by letting users (who really want all this) own-build current shim, and then we use the (apparently deprecated/unsupported) feature of OVERRIDE_SECURITY_POLICY to ensure that SBAT is checked on all subsequently loaded images.

Without focussing too much on our specific loader, has enough thought been given to how non-GRUB loaders will opt in to SBAT if they want to? Especially if SBAT cannot be obtained roughly as we are doing, by inserting (just) an own-build shim (i.e. with current SBAT) into the boot process.

[julian-klode]

@mikebeaton I think you have some misconceptions there, grub is not needed for sbat, and doesn't implement any sbat functionality, all that lives in shim and it of course works with any boot loader that uses the shim protocol, systemd-boot being the major other player.

[mikebeaton]

I do not have the misconception that grub is needed for sbat. If the proposal here automatically loads these other binaries (with SBAT updates) purely in shim, that is okay, although:

• one would need to understand how shim will find these, and confirm that all/any valid shims could do so
  • I perhaps misread the proposal as meaning that files loaded further down the standard (grub+shim) boot chain, i.e. after shim, will contain these updates
• I would also note that the (unsupported/neglected) OVERRIDE_SECURITY_POLICY is much much convenient for other loaders coming after shim, as it means that SBAT is 'just' included (in LoadImage), whereas currently SBAT is only passed on to grub by the Shim Lock protocol - i.e. anything which wants to use SBAT at least has to be Shim Lock protocol aware
  • If this requirement is intended and to be retained (i.e. OVERRIDE_SECURITY_POLICY will not/cannot be supported), then this is a new - and I believe not particularly documented? - load on any (non-standard-grb+shim) loader which wants to adopt SBAT

[julian-klode]

The revocations.efi will be shipped by the same vendor as the shim, so that's not a problem. It just unties the SBAT revocation from needing a shim update. It's up to the vendor to ensure this works.

I do not know what OVERRIDE_SECURITY_POLICY is. I know we have some hooking for LoadImage but it's not useful in that you cannot actually use the shim to verify images. Work is ongoing to make shim actually hook LoadImage and provide that functionality with verification.

[mikebeaton]

The revocations.efi will be shipped by the same vendor as the shim, so that's not a problem. It just unties the SBAT revocation from needing a shim update. It's up to the vendor to ensure this works.

I do not know what OVERRIDE_SECURITY_POLICY is. I know we have some hooking for LoadImage but it's not useful in that you cannot actually use the shim to verify images. Work is ongoing to make shim actually hook LoadImage and provide that functionality with verification.

It does work already, we are using it. If you set OVERRIDE_SECURITY_POLICY compilation variable, shim hooks SECURITY2_PROTOCOL_GUID (if available) and SECURITY_PROTOCOL_GUID (required). The subsequent loader then has to set NVRAM var gShimLockGuid:ShimRetainProtocol, in order for these hooks to be retained after the the first image load which it makes. Once this is done, this already works, and enforces SBAT in LoadImage, with existing shim. The only thing required for all this to work, with existing shim code, is the corrected export for OVERRIDE_SECURITY_POLICY discussed in #596.