fwupdate should be able to update uefi's revocation list

[johannbg]

UEFI just recently updated it's revocation list [1] ( was last updated on August 8, 2016 prior to that ) due to a security hole in Grub and fwupd seems to be the most natural cross distribution place to handle such update hence I asked has there been any thought including that functionality in fwupd ?

1. https://eclypsium.com/2020/07/29/theres-a-hole-in-the-boot/
2. http://uefi.org/revocationlistfile

[hughsie]

I think the current plan is to manage this in dbxtool. @vathpela would be able to say more.

[vathpela]

Yeah, it'll be updated in the next couple of days; there are a couple of things that need to happen first to avoid bricking some boxes.

[johannbg]

I knew that @vathpela would take care of this in RH ecosystem and dbxtool would be used to update it there. What I'm talking about is moving the role and function of dbxtool into fwup and manage this there instead in which the end users could get notified that there is an updated of the revocation list ( otherwise the end user might for example simply power of the device in the middle of update and brick his laptop ) and we would not have two 2 services/tools effectively in the same role and bunch of other bells and whistles you get with fwup.

On top of that users are disabling dbxtool service while they aren't disabling fwupd and fwupd has more potential being more widely deployed than dbxtool ever will be.

[superm1]

All the distros have adopted something similar to dbxtool if not that directly. Remember all these tools are actually glorified dd. I understand the spirit of this request but it's actually a risk if fwupd rolled out dbx updates without distros blessings. For example if dbx file has revocations for the distro bootloader hashes, rolling it out will 🧱 the box unless user turns off secure boot.

[johannbg]

fwupd is the middle layer between distro's and oem's which arguably makes it the best place to push collaborated coordinated update and even get manufactures ( like lenovo ) to test the update on their hardware which is one of the problems here.

Presumably the users will be recommended to turn that off regardless and the tools made not to update this unless secure boot has been turned off since people will sue whomever ( the OS or the manufacturer ) if the update fails and this is not covered under warranty after spending $$$$ for a laptop which suddenly got bricked by an update ( which is probably what will happen with dual booters we all love those right and one of the reason why Microsoft/OEM's backed out of it last time as in things started getting bricked and someone sued and known security holes never have been closed as a result or fear of that ).

fwup already has a legal clause in place to cover it right ( since it's already pokes things that might break ) while dbxtool might not.

[johannbg]

On top of that fwup is integrated into the software update notification in the desktop environments thus capable of relaying the message to the end users that they might need to turn secure boot off prior to the update. Not sure how distribution plan on solving that problem with tools like dbxtool.

[superm1]

On top of that fwup is integrated into the software update notification in the desktop environments thus capable of relaying the message to the end users that they might need to turn secure boot off prior to the update. Not sure how distribution plan on solving that problem with tools like dbxtool.

In no world would should a distro tell a user to turn off secure boot when an update is coming in case it bricked their system. The reason that it makes sense for distros to control the roll out with dbxtool/mokutil is that they come down from the updater in tandem. The dnf/apt type package managers of the world will allow both kernel, shim, grub, dbxtool and the like to be updated at the same time. Distro packagers can make dependencies where updated dbx only gets installed if the updated bootloader is installed. If fwupd handles the roll out that is completely gone, and it's asking for lots of systems that can't boot.

Let me give you a doomsday scenario:

1. You're working from home, you have a corporate assigned machine.
2. Said corporate machine has a BIOS admin password set by your corporation and stored in escrow.
3. You can normally use escrow to check out the admin password on a one off basis to make some BIOS changes, but a service updates it, reverts BIOS settings you're not supposed to change and stores the new one in escrow.
4. Your corporation is staging updates for all distro packages until they've validated them. So no fixed grub/shim yet.
5. Fwupd comes in and applies the dbx update.
6. You reboot, can't boot anymore. Can't change BIOS settings to turn off secure boot because you can't get your password out of escrow. Can't get to escrow service without VPN.

I don't think it's that far-fetched either. I know of corporations that manage their BIOS admin passwords this way, and will stage their rollouts of updates to prevent field bricking.

It's the exact same reason that you'll notice no OEM is bundling the dbx with a BIOS upgrade in the near future. It's a dependency you can't represent when updates come from different parties.

[johannbg]

fwup is decouple from the regular distro update process hence you could update the components then proceed with update through fwup and in "corporate" the entire update process from firmware to OS is a controlled process so corporations are not a concern here the novice end user is.

That said OEM and the industry has been sold a solution that does not work in practice since the weakest link in the secure boot chain ( and basically anything that relies on certificates ) is the lack of code validation by the CA, the time it takes to revoke a compromised certificate, vendors pushing updates and end user finally installing the update so I personally dont even see why we are even bothering advocating "secure boot" which is anything but secure after all.

People can easily bypass any traditional CA provider vetting process which usually involves no more than then CA checking country company registry and perhaps call a phone number, by creating a fake company in countries for example in the UK with an fake address ( a process that takes probably no more than 10 minutes these days and is not vetted ) with an offshore account on the British virgin islands then get a certificate issued by the "established CA" pass their vetting process" and go about doing the "evil" things they plan on doing until they get discovered and their certificate revoked.

In anycase it's Friday there is no point in having any circular argument in which both parties fundamentally agree on the same thing just not where they should be addressed. If upstream does not believe that this should be handled there is no point discussing it any further.

[superm1]

Of course the weakest link in security is always the people aspect.

You can't go and just get your own CA and have it be trusted by the secure boot ecosystem. It has to be enrolled into your firmware. The CA here is the Microsoft UEFI 3rd party CA. To get a shim signed it has to go through the shim review process which is a cross distro process of others verifying our your grub binary that it loads has sane patches and no gaping holes.

In the case of the recent disclosure no amount of that type of review catches these problems in GRUB.

In anycase it's Friday there is no point in having any circular argument in which both parties fundamentally agree on the same thing just not where they should be addressed. If upstream does not believe that this should be handled there is no point discussing it any further.

I think if we have a fundamental shift in terms of how secure boot was done on Linux (for example all distros use the same signed bootloader compiled by the LF and collaborate on the source that goes into it) we should revisit this. But with the current model, yes status quo. @hughsie feel free to agree/disagree anywhere here.

[johannbg]

Of course the weakest link in security is always the people aspect.

You can't go and just get your own CA and have it be trusted by the secure boot ecosystem. It has to be enrolled into your firmware. The CA here is the Microsoft UEFI 3rd party CA. To get a shim signed it has to go through the shim review process which is a cross distro process of others verifying our your grub binary that it loads has sane patches and no gaping holes.

What you just need is not enough reliable bootloaders signed by Microsoft key which is why there is an exploit in the wild based on for example the signed Kaspersky Rescue Disk files ( hole that will probably be closed with this update if the Kaspersky certificate will be revoked ).

In the case of the recent disclosure no amount of that type of review catches these problems in GRUB.

In anycase it's Friday there is no point in having any circular argument in which both parties fundamentally agree on the same thing just not where they should be addressed. If upstream does not believe that this should be handled there is no point discussing it any further.

I think if we have a fundamental shift in terms of how secure boot was done on Linux (for example all distros use the same signed bootloader compiled by the LF and collaborate on the source that goes into it) we should revisit this. But with the current model, yes status quo. @hughsie feel free to agree/disagree anywhere here.

It's not just the distro's since you just need any unreliable bootloader signed by the Microsoft key ( which could be a Linux based bootloader or not ). Once that bootloader has been obtained an exploit can be created which later can be installed thus used for nefarious purposes whatever those nefarious purposes might be so you would need it to be the same maintained and used bootloader across the OS and the industry which is as unlikely to happen as distro's agreeing on a single one.

[superm1]

It's not just the distro's since you just need any unreliable bootloader signed by the Microsoft key ( which could be a Linux based bootloader or not ). Once that bootloader has been obtained an exploit can be created

Completely on point. In this circumstance we're all relying upon the distros and their security team to roll out dbx (no dependency on making sure your active bootloader was revoked).

Back to my point about a fundamental shift. Having the Microsoft CA that can sign anything is absolutely the weak point in that example.

so you would need it to be the same maintained and used bootloader across the OS and the industry which is as unlikely to happen as distro's agreeing on a single one.

Yup. It's a balancing act between freedom and security. systemd-boot is probably the closest thing we've got to this, but obviously there is no rallying around it.

[johannbg]

systemd-boot is probably the closest thing we've got to this, but obviously there is no rallying around it.

That's basically just because we have simply not been pushing sd-boot which I dont think will be particular hard to do compared to getting the distro's to switch to systemd once we decide to do that since Grub has never been particularly well liked component by end users and I'm already looking into getting sd-boot into Fedora as an installable option for UEFI boot but it indeed would be the most viable/logical option since systemd covers ( by my last count ) around 220 linux distro's and bunch of other manufacturer linux based device so it might cover the SBC/IoT space on Linux as well and sd-boot would have a guarantee maintainership for the duration of the system management framwork since it resides in the systemd repo.