[prev in list] [next in list] [prev in thread] [next in thread] 

List:       fedora-devel-list
Subject:    Re: future of dual booting Windows and Fedora, redux
From:       Florian Weimer <fweimer () redhat ! com>
Date:       2022-07-29 11:52:28
Message-ID: 877d3w6sqr.fsf () oldenburg ! str ! redhat ! com
[Download RAW message or body]

* Daniel P. Berrangé:

>> Unfortunately, Fedora promoted this broken model with pervasive
>> cross-distribution/cross-OS trust as well.  People are generally quick
>> to criticize those who control a PKI, but very few organizations are
>> willing to step up to hold the key material for the key of last resort
>> because of the risk inherent to that.  Consequently, pretty much all
>> distributions hide behind the Microsoft key, instead of running their
>> own PKI and working with OEMs to get it accepted by the firmware.
>
> Would the situation actually be any different in that case ? Assume
> an alternate reality where hardware OEMs magically agreed to pre-install
> 20 different keys for the various Linux vendors.
>
> You still have the same "problem" that you're running 1 specific vendor's
> OS, but your firmware trusts the software from countless different
> unrelated vendors for SecureBoot.

No, in this model, if you buy a Fedora server, it only boots Fedora
until manual intervention.  I don't think this is a problem because
Secure Boot with that very open signing policy is not very far from
disabled Secure Boot.

> Either way though, IIUC, this ought not to be a problem if combining
> SecureBoot with TPM measurements. The firmware measures the SecureBoot
> signing key of the OS binary that is booted into PCR 7.
>
> So if BitLocker keys are tied to PCR-7 when it was booted with the
> Microsoft Windows UEFI CA, then any attempt to boot an OS signed by
> the Microsoft 3rd Party UEFI CA would get different PCR-7 measurements
> and so BitLocker keys are safe.

If Microsoft is confident that their boot path has physical presence
checks before destructive operations, they can enable booting from media
(even the network by default).  That can be used to add powerful
recovery tools for their users.

Right now, that's risky because pretty much all Linux distributions
allow you to create an initrd that wipes all storage media.  It's also
more likely that you can run code before certain Secure Boot milestones
have been rached during the boot process.  (And of course it's also
possible to impersonate the Windows login screen and log the user's
password this.)  As far as I understand it, Microsoft has locked down
the early boot process to a significant degree (even extending to
userspace), so these types of attacks are less likely to be successful
in a Windows-only environment.  Locking out other bootloaders by default
as a defense-in-depth measure doesn't seem so far-fetched to me.

Honestly, I had expected this to happen far sooner, and only over time
assumed that it would probably never happen for some non-security
reasons.

Thanks,
Florian
_______________________________________________
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-leave@lists.fedoraproject.org
Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Do not reply to spam on the list, report it: https://pagure.io/fedora-infrastructure

[prev in list] [next in list] [prev in thread] [next in thread]