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

From: Matthew Garrett
Date: Tue Nov 06 2012 - 08:16:34 EST


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@xxxxxxxxxxxxx
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/