Proposed F19 Feature: Package Signature Checking During Installation

[Florian Weimer]

On 01/09/2013 02:34 PM, Matthew Garrett wrote:
> On Wed, Jan 09, 2013 at 01:52:05PM +0100, Florian Weimer wrote:
>
>> 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.
>
> I don't understand what you mean by "already-signed boot path", and I
> don't see how F18 has anything to do with this.

Let's say I want to replace packages in the official, cryptographically 
signed F19 installation media.  Let's assume further that we tell our 
users to verify the signature just by booting from the media.

I start with the F18 TC3 image, which boots on Secure Boot systems, 
replace the boot artwork (which is not cryptographically protected), the 
F18 kernel, and use most of the F19 installation environment.  The F18 
boot loader and kernel know nothing about image verification or 
Authenticode-style executable verification, so it will start any init I 
supply.  This means that I can start a fake anaconda which looks just 
like F19, but does not verify RPM signatures (as before).  At this 
point, I can put whatever RPMs I want on the installation media, and 
they will be installed.

(I might even be able to use the F19 kernel if the shim-embedded CA 
hasn't changed keys.)

>> 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:
>
> If I have physical access to your system then I can just write my own
> keys directly into flash with an SPI programmer. That's never been the
> threat model.

True.  But if we want to use Secure Boot for image verification, we need 
to cover the case where the user willingly boots from a tampered-with 
image (modified outside the cryptographically protected part, 
obviously).  These needs additional guarantees from the folks 
participating in the Secure Boot PKI, and I really doubt they are there 
(and apparently, so do you).

-- 
Florian Weimer / Red Hat Product Security Team