On 05/06/2013 02:09 AM, Lars Seipel wrote:
On Sat, May 04, 2013 at 01:03:11AM -0500, Chris Adams wrote:
However, unless your installer image is signed, checking RPM signatures
in anaconda is pointless (which is why the feature you mentioned is
based on Secure Boot). If someone was going to the trouble of changing
the RPM signatures, they could also change the public keys included in
anaconda.
Hmm.
- the checksums for netinstall images are signed with a Fedora key
- the corresponding public key is made available through https
- therefore the integrity of installer images can be verified
Obtaining an SSL certificate for fedoraproject.org shouldn't be much
easier than getting your code signed to run under Secure Boot.
Actually, it should be practically indefeasible to obtain a certificate
for fedoraproject.org from a browser CA without consent from the Fedora
project (or Red Hat). There have been several incidents where
certificates were issued in a non-compliant manner by browser CAs, but
there are guidelines, processes and compliance audits which aim to
reduce such risks.
In contrast, the Microsoft signing process for third party UEFI drivers
has no safeguards whatever to prevent anyone from getting a signature on
something that poses as a Fedora installer (or Windows installer, for
that matter). This is not Microsoft's fault—it is just not evident from
a first stage boot loader what it will eventually boot. And from a user
point of view, all UEFI driver signatures are alike because they do not
embed a cleartext developer name. (Not that UEFI firmware has
Authenticode prompts which show the certificate on the driver.)
--
Florian Weimer / Red Hat Product Security Team
--
devel mailing list
devel@xxxxxxxxxxxxxxxxxxxxxxx
https://admin.fedoraproject.org/mailman/listinfo/devel
