[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:       Daniel =?utf-8?B?UC4gQmVycmFuZ8Op?= <berrange () redhat ! com>
Date:       2022-07-29 10:08:38
Message-ID: YuOxpv2+HBPlW6Qb () redhat ! com
[Download RAW message or body]

On Fri, Jul 29, 2022 at 11:26:15AM +0200, Florian Weimer wrote:
> * Vitaly Zaitsev via devel:
> 
> > On 26/07/2022 20:05, Chris Murphy wrote:
> > > Summary: Windows 10/11 increasingly enables Bitlocker (full disk encryption) \
> > > out of the box with the encryption key sealed in the TPM. Two different issues \
> > > result:
> > 
> > Microsoft has published a new security bulletin on the current state
> > of Secure Boot:
> > https://docs.microsoft.com/en-us/windows/security/information-protection/secure-the-windows-10-boot-process
> >  
> > The most important note:
> > 
> > > Secured-core PCs require Secure Boot to be enabled and configured to distrust \
> > > the Microsoft 3rd Party UEFI CA signature, by default, to provide customers \
> > > with the most secure configuration of their PCs possible.
> > 
> > TL;DR. The new certified by Microsoft devices will be able to load
> > only Microsoft Windows in the UEFI Secure Boot enabled mode.
> > 
> > "Microsoft <3 Linux", "Microsoft is a friend", "Microsoft has
> > changed", - they said.
> 
> But they also say this:
> 
> > The default state of Secure Boot has a wide circle of trust which can
> > result in customers trusting boot components they may not need. Since
> > the Microsoft 3rd Party UEFI CA certificate signs the bootloaders for
> > all Linux distributions, trusting the Microsoft 3rd Party UEFI CA
> > signature in the UEFI database increase[]s the attack surface of
> > systems. A customer who intended to only trust and boot a single Linux
> > distribution will trust all distributions–much more than their desired
> > configuration.
> 
> And this is an accurate description of the situation. 
> 
> 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.

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.

On the Linux side, IIUC shim will measure the certificate that signed
the Linux OS it loads into PCR-7 too. So if the Linux guest ties LUKS
keys to PCR-7, then again it should be secure[1] against someone trying
to boot a different Linux vendor's OS.

With regards,
Daniel

[1] I'm ignoring the inconvenient initrd hole that exists in more
    or less all Linux OS wrt boot measurements. That's a technical
    impl flaw, rather than an inherant problem of the SecureBoot/TPM
    techology.
-- 
> > https://berrange.com      -o-    https://www.flickr.com/photos/dberrange :|
> > https://libvirt.org         -o-            https://fstop138.berrange.com :|
> > https://entangle-photo.org    -o-    https://www.instagram.com/dberrange :|
_______________________________________________
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]