linux-kernel - Re: Firmware signing -- Re: [PATCH 00/27] security, efi: Add kernel lockdown

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Date:   Tue, 14 Nov 2017 14:31:36 -0800
From:   James Bottomley <James.Bottomley@...senPartnership.com>
To:     Matthew Garrett <mjg59@...gle.com>
Cc:     "Luis R. Rodriguez" <mcgrof@...nel.org>,
        Linus Torvalds <torvalds@...ux-foundation.org>,
        Johannes Berg <johannes@...solutions.net>,
        Mimi Zohar <zohar@...ux.vnet.ibm.com>,
        David Howells <dhowells@...hat.com>,
        Alan Cox <gnomes@...rguk.ukuu.org.uk>,
        "AKASHI, Takahiro" <takahiro.akashi@...aro.org>,
        Greg Kroah-Hartman <gregkh@...uxfoundation.org>,
        Jan Blunck <jblunck@...radead.org>,
        Julia Lawall <julia.lawall@...6.fr>,
        Marcus Meissner <meissner@...e.de>, Gary Lin <GLin@...e.com>,
        LSM List <linux-security-module@...r.kernel.org>,
        linux-efi <linux-efi@...r.kernel.org>,
        Linux Kernel Mailing List <linux-kernel@...r.kernel.org>
Subject: Re: Firmware signing -- Re: [PATCH 00/27] security, efi: Add kernel
 lockdown

On Tue, 2017-11-14 at 14:17 -0800, Matthew Garrett wrote:
> On Tue, Nov 14, 2017 at 2:14 PM, James Bottomley
> <James.Bottomley@...senpartnership.com> wrote:
> > 
> > On Tue, 2017-11-14 at 15:55 -0500, Matthew Garrett wrote:
> > > 
> > > TPM-backed Trusted Boot means you don't /need/ to sign anything,
> > > since the measurements of what you loaded will end up in the TPM.
> > > But signatures make it a lot easier, since you can just assert
> > > that only signed material will be loaded and so you only need to
> > > measure the kernel and the trusted keys.
> > 
> > Actually, I'd disagree with that quite a lot: measured boot only
> > works if you're attesting to something outside of your system that
> > has the capability for doing something about a wrong
> > measurement.  Absent that, measured boot has no safety
> > whatsoever.  Secure boot, on the other hand, can enforce not
> > booting with elements that fail the signature check.
> 
> Measured boot has a great deal of value in the sealing of private
> material, even in the absence of attestation. The way Microsoft make
> use of PCR7 is a good example of how signatures make this easier -
> achieving the same goal with a full measurement of the boot chain
> instead of relying on signature validation results in significantly
> more fragility.

OK, so I agree that if you have sealed something required for boot (and
have the capability for resealing it on OS upgrade) you can use
measurements locally.  However, I don't believe we have any systems
today in Linux which can do this (we have theoretical ideas about how
we might do it with LUKS root keys and one day we might actually have
the infrastructure to make it viable for a standard laptop).

Absent that, secure boot provides a reasonable measure of security
which works with today's infrastructure.

Note: this doesn't mean I necessarily want signatures everywhere (like
firmware).  We can sign elements in blobs that provide the effective
security without needing more granular signatures.

James