Proposed F19 Feature: Package Signature Checking During Installation

[Peter Jones]

On Wed, Jan 09, 2013 at 01:52:05PM +0100, Florian Weimer wrote:
> On 01/08/2013 04:25 PM, Jaroslav Reznik wrote:
> >Following the implementation of Features/SecureBoot, we can extend the Secure
> >Boot keys as a root of trust provided by the hardware against which we can
> >verify a signature on our key files, thus guaranteeing that they're from the
> >same source as the boot media.
> 
> It just occurred to me that this has zero chance of working because
> an attacker can always take the already-signed boot path from the
> F18 installer and use that to boot a modified F19 installation
> image.   We cannot retroactively add these checks to the F18
> installation images (or F18 installations).  We could theoretically
> revoke the signatures on the F18 binaries, but this would not go
> well with our users.

Sure; the intent here is to allow the images to validate the repos.
Some other mechanism is also needed for a complete solution for
guaranteeing the authenticity of installation images.  It's a problem
which should still be addressed, but it isn't the threat model being
addressed here.

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.

> This is related to the lack of universally agreed-upon semantics for
> Secure Boot.  A Secure Boot signature does not mean that the image
> is harmless to boot.  I've recently raised this ambiguity on the
> oss-security mailing list in the "Plug-and-wipe and Secure Boot
> semantics" thread:
> 
> <http://www.openwall.com/lists/oss-security/2012/12/18/1>

There's no ambiguity, you've just completely mischaracterized the threat
model Secure Boot is meant to address, and found that it does not solve
problems unrelated to that threat.

I'm *extending* its abilities to also cover other threats, just not
(currently) the threat you appear to be concerned with.

-- 
        Peter