On Thu, 2013-01-10 at 17:56 +0100, Till Maas wrote: > On Wed, Jan 09, 2013 at 10:09:21AM -0500, Peter Jones wrote: > > > As it stands you still need to verify that your netinst.iso (or > > whatever) boot image is what you mean to be using. There are ways we > > can address that, but it's not the problem I'm trying to solve with this > > particular feature. > > > > I'm not claiming to solve every integrity or authenticity problem we've > > got. I'm just making it so that anaconda can verify packages are okay > > to install. I'm not solving the greater problem of trusting anaconda. > > I've found that it's often useful to work on one engineering problem at > > a time. > > But why should anaconda not verify packages if secure boot is disabled? For the same reason Firefox doesn't automatically accept self-signed SSL certs, and the same reason that ssh doesn't automatically accept new host keys: it'd be creating trust from thin air. With secure boot disabled there's no root of trust for verification. You could verify that the signatures were _valid_, but you'd have no grounds to conclude from their validity that the signatures were the ones put there by The Fedora Project, and therefore that the package contains the data that The Fedora Project intended it to contain. You'd only know that the key the repo says signed the packages did in fact sign the packages. That's not security. That's theatre. The "hello world" app Peter is describing, as part of the data covered by Microsoft's signature, contains the public half of the package signing key. The signing process for that app is as rigorous as getting a Windows driver signed. Secure Boot machines ship with the keys necessary to validate that signature. Therefore, with the chain of trust he's building, the _platform_ asserts that the package signatures are valid. It changes the attack vector from "someone trojaned some random repository on the internet" to "someone managed to root this machine's firmware before it even shipped". And Microsoft is the party with most to lose here, afaict the reason they want Secure Boot is because rooting the firmware is a _major_ problem for them, and it's easier to cryptographically tripwire the firmware than to make Windows secure. Platforms with rooted (or even rootable) firmware now become platforms that won't run Windows. That's one hell of an economic incentive. And if you don't trust the firmware, what on earth makes you think you can trust anything that runs afterwards? Hint: don't say coreboot unless, at minimum, you can reflash the board without powering it on. - ajax
Attachment:
signature.asc
Description: This is a digitally signed message part
-- devel mailing list devel@xxxxxxxxxxxxxxxxxxxxxxx https://admin.fedoraproject.org/mailman/listinfo/devel
