search

coreos / fedora-coreos-tracker

Issue tracker for Fedora CoreOS
https://fedoraproject.org/coreos/
262 stars 59 forks source link

Regular updates for the UEFI revoked signatures database (dbx) #1478

Open dustymabe opened 1 year ago

dustymabe commented 1 year ago

In https://github.com/coreos/fedora-coreos-tracker/issues/1452#issuecomment-1500538526 we determined that we'd like to explore regular updates to the UEFI revoked signatures database in order to keep our systems at least not booting known bad bootloaders/software.

There are several investigations that would need to take place first and we'd also need to implement https://github.com/coreos/fedora-coreos-tracker/issues/1468 because we can't really update the dbx without having a good policy on keeping the bootloader up to date.

dustymabe commented 1 year ago

Copying the comment from @bgilbert in https://github.com/coreos/fedora-coreos-tracker/issues/1452#issuecomment-1496883552 here since I think it will be useful for this ticket:

At present we're automatically updating neither shim/GRUB nor the dbx denylist. That has some consequences:

  1. Old installs will continue to work on old hardware as long as dbx isn't manually updated. We do ship fwupd and dbxtool (the dbx updater used by fwupd) and a user could invoke fwupdmgr update without updating their bootloader first. If fwupd allows this, it'll brick the bootloader. fwupd has code to refuse the update if the ESP has EFI binaries with old signatures, but we don't know how fwupd responds to FCOS's ESP quirks.
    • Investigate: in a FCOS VM with old UEFI firmware, upgraded from a very old FCOS release, and with an old bootloader, does fwupdmgr update correctly refuse to update dbx? What about on a system installed with boot_device.mirror?
  2. Old install images will not boot in Secure Boot mode on UEFI firmware with newer dbx. Those images aren't supported anyway, so this seems fine.
  3. By not automatically updating dbx, we're leaving older installs vulnerable to Secure Boot bypass via exploitation of a compromised bootloader (either the one we shipped, or a different one listed in newer dbx).
    • Investigate: in a FCOS VM with old UEFI firmware, upgraded from a very old FCOS release, and with a bootloader updated via bootupd, does fwupdmgr update correctly update dbx? What about on a system installed with boot_device.mirror?
    • Decide: how do we want to handle this? Pursue automatic bootloader + dbx updates? Document using fwupd to manually update dbx? We generally design FCOS not to require manual steps to maintain best-practice security.
dustymabe commented 1 year ago

some passing discussion with @jmflinuxtx I had on this topic:

2023-04-05 13:11:07 dustymabe   do other Fedora editions automated dbx updates? (we're discussing this in #fedora-meeting-1)
2023-04-05 13:40:01 jforbes It is possible, but I don't think it is done in practice
2023-04-05 13:41:23 jforbes In fact, it seems a rather bad idea. We can blacklist in other places if need be
2023-04-05 13:42:26 dustymabe   oh? bad idea
2023-04-05 13:43:41 dustymabe   I'd definitely be interested in your take on the discussion we just had in #fedora-meeting-1
2023-04-05 13:44:34 dustymabe   there are a lot of low level things that would be good to get some perspective from an expert
2023-04-05 13:44:53  *  dustymabe has to step away for an hour - bbiab
2023-04-05 14:02:35 jforbes So yeah, in theory automated dbx updates sound good, in practice who knows what they may break otherwise. It is usually best to have a user initiate any firmware updates so they are at least aware. You have to call fwupd to update it in the desktop spin, though gnome software will nag you that you have outstanding security updates until you do.
2023-04-05 14:03:52 jforbes We can also blacklist in shim or even in a kernel keyring if necessary, though that doesn't protect us from a compromised shim if it is signed by a key that would be blacklisted.
2023-04-05 14:04:04 jforbes It would be worth a conversation with rharwood over it.
dustymabe commented 1 year ago

We discussed this in the community meeting today.

13:05:10  dustymabe | #action dustymabe to invite grub and kernel folks to discuss
                    | this topic further
prestist commented 1 year ago

We discussed this in the community meeting today

travier commented 1 year ago

Ticket to submit a Fedora Change in: https://github.com/coreos/fedora-coreos-tracker/issues/1512