linux-kernel - Re: [RFC] Second attempt at kernel secure boot support

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]

Message-ID: <20121106131634.GA1818@srcf.ucam.org>
Date:	Tue, 6 Nov 2012 13:16:34 +0000
From:	Matthew Garrett <mjg@...hat.com>
To:	Jiri Kosina <jkosina@...e.cz>
Cc:	linux-kernel@...r.kernel.org,
	linux-security-module@...r.kernel.org, linux-efi@...r.kernel.org,
	James Bottomley <James.Bottomley@...senPartnership.com>,
	Shea Levy <shea@...alevy.com>, Vivek Goyal <vgoyal@...hat.com>
Subject: Re: [RFC] Second attempt at kernel secure boot support

On Tue, Nov 06, 2012 at 01:51:15PM +0100, Jiri Kosina wrote:
> On Wed, 31 Oct 2012, Matthew Garrett wrote:
> > shim generates a public and private key. 
> 
> It seems to me that this brings quite a huge delay into the boot process 
> both for "regular" and resume cases (as shim has no way to know what is 
> going to happen next). Mostly because obtaining enough entropy is 
> generally very difficult when we have just shim running, right?

pseudorandom keys should be sufficient here. It's intended to deal with 
the case of an automated attack rather than a deliberate effort to break 
into a given user's system.

> > It hands the kernel the private key in a boot parameter and stores the 
> > public key in a boot variable. On suspend, the kernel signs the suspend 
> > image with that private key and discards it. On the next boot, shim 
> > generates a new key pair and hands the new private key to the kernel 
> > along with the old public key. The kernel verifies the suspend image 
> > before resuming it. The only way to subvert this would be to be able to 
> > access kernel memory directly, which means the attacker has already won.
> 
> I like this protocol, but after some off-line discussions, I still have 
> doubts about it. Namely: how do we make sure that there is noone tampering 
> with the variable?

The variable has the same level of security as MOK, so that would be a 
more attractive target.

> - consider securely booted win8 (no Linux installed on that machine, so 
>   the variable for storing public key doesn't exist yet), possibly being 
>   taken over by a malicious user
> - he/she creates this secure variable from within the win8 and stores 
>   his/her own public key into it

You can't create a non-RT variable from the OS.

> - he/she supplies a signed shim (as provided by some Linux distro vendor), 
>   signed kernel (as provided by some Linux distro vendor) and specially 
>   crafted resume image, signed by his/her own private key

shim detects that the key has the RT bit set and deletes it.

> - he/she reboots the machine in a way that shim+distro kernel+hacker's S4 
>   image is used to resume

And so this step can't happen.

-- 
Matthew Garrett | mjg59@...f.ucam.org
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/