-
Notifications
You must be signed in to change notification settings - Fork 288
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
RFC: Revocation Delivery Proposal #655
Comments
I posted this issue under the shim repo since more folks are likely to see it here. I expect this to mostly be implemented in https://github.com/rhboot/certwrapper unless I find a bug with the revocation.efi support in shim. Additional information on the bootmgr SKU Si revocation mechanism can be found here: |
I was pinged about this today -- and I'm wondering what exactly fwupd and the LVFS should do. For instance, could we read |
LVFS could distribute revocations.efi as well, but it's also not strictly necessary. It might be good to have that mechanism in place in case we ever had to rapidly respond to something bad happening. I'm not sure I entirely understand what you mean by the check. Would that basically be an audit that would flag if a system is not up to date? That might be nice to have. |
Yes -- although I'm a bit unsure where the "canonical truth" is for the
|
At the moment, the canonical truth for SbatLevel is tracked here: https://github.com/rhboot/shim/blob/main/SbatLevel_Variable.txt However as part of addressing this issue, I very much want to make that a single (probably sub) repo that will drive building the various pieces. |
I don't think that document qualifies as canonical truth :) |
Problem:
Revocations beyond dbx require updating non-authenticated boot
services variables. Unlike the signed dbx blobs that can be applied at
runtime independently from updating the first stage bootloader, these
revocations were initially built into shim as an optional “latest” and
automatic payload. These payloads exist for both SBAT (shim based
Linux distros) and SKU Si (bootmgr based Windows distros). Binaries
from both ecosystems can be used to attack both ecosystems on typical
systems that trust both the UEFI and Window CA.
While automatically putting a system into the most secure state
possible by applying the latest revocation quickly is desirable, it
carries a very real risk of preventing a legitimately installed system
from booting. These scenarios are fall-back after and update and dual
boot. While shim now supports picking up the revocation payload from a
separate binary blob that can be updated independently from shim, the
policy for deploying this blob will depend on how a particular system
is being managed, similar to how dbx updates are being deployed.
Current state:
Most Linux distros are able to deliver a built-in automatic SBAT
revocation that revokes binaries that are roughly 1 year old or
older. Ones that are not have shifted to an empty automatic SBAT
payload. All Linux distros deliver a shim that allows an opt-in SKU Si
revocation to be applied, none of them do this automatically.
Windows currently only applies SKU Si revocations based on a manual
opt-in and does not deliver SBAT revocations.
Proposal:
Systems should automatically apply the most recent payload for the
ecosystem they are not in, unless the other binary is seen as an
active bootloader before the one being booted on the boot list. (XXX:
This seems awfully complex to protect dual boot systems that already
have terrible compatibility. - Still this should be handled the same
way by shim and bootmgr)
Systems that potentially need to support falling back to an older
version of the same OS will need to manage revocations either manually
or as part of an automated orchestration that drives the update /
fallback process above the OS instance.
Solution:
Deliver revocations in a separate package that has dependencies that
prevent it from being installed on an OS that it would revoke. This
package also delivers previous revocations in cumulative blobs. Which
revocation is put in place for shim to install can be configured as:
Apply the most recent revocation that does not revoke the OS being
updated to.
Apply the most recent revocation that does not revoke the OS being
updated from.
Apply the most recent revocation that does not revoke the OS
installed at an alternate, supplied, mount location.
Manually lock revocations at a specific level.
Defaulting to (2) where (2) is effectively (1) for a fresh install.
Optional dual boot friendly packages:
Deliver an alternate stream of these packages that do not deliver SKU
Si revocations for dual boot systems that an admin can opt into under
the assumption that they are sometimes booting Windows and want
Windows to manage its own revocations.
Rejected Proposal:
Record the hash of in-use bootloaders and add them to an SBAT specific
exception list that allows only that binary to elude SBAT based
revocation at the same time as applying the revocation.
Pros:
- This would protect from automated attacks using a binary that
doesn't precisely match the one listed by hash.
Cons:
- The fallback OS version could be updated to an intermediate
version.
- Complex to apply correctly without risking a roll-back attack.
shim would need to examine the binary and determine that it matches
the sbat level that's being revoked at the same time. This creates
a new, non-trivial attack surface.
Orthogonal concept:
Generic UEFI CA signed revocation.efi binaries could be delivered to fwupd
and installed via that framework.
The text was updated successfully, but these errors were encountered: