[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Re: [RFC][PATCH] UEFI Secure Boot support

On Fri, Dec 06, 2013 at 06:04:50PM +0000, Colin Watson wrote:
> In the UEFI Secure Boot session at this year's DebConf - unfortunately
> there were no ftpmasters there - I noted that I'd implemented the
> signing system that Ubuntu uses to support UEFI Secure Boot; I talked to
> Mark Hymers briefly about this at the mini-DebConf in Cambridge last
> month.  He seemed generally willing to offer broadly the same interfaces
> as Ubuntu (which would make my life as grub2 maintainer much simpler),
> but obviously wanted to see a patch.
> The general idea here is to sign a boot loader image (i.e. GRUB) with a
> Debian key: for reasons best known to the UEFI specifiers, this has to
> be a 2048-bit RSA key.

Nuh-unh! You can also go much smaller! :)

> The public half of this Debian key would be
> embedded in the shim package, which we would then submit to Microsoft
> for their signature [1].

Does shim still do that thing where it boots any kernel that looks like
Linux without verifying it's integrety?

> Upgrading shim would be fairly inconvenient,
> but that doesn't have to be done very often, and this effectively
> arranges to delegate control to a Debian key so that we can change GRUB
> much more easily.  shim also implements the "Machine Owner Key" scheme
> so that we can give users a way to add user-controlled signing keys
> without having to figure out how to get at setup mode [2].
> Storing sensitive data such as the private half of Debian's UEFI signing
> key on the buildds is obviously a non-starter, so the signing has to
> happen on ftp-master.  The simplest way to do this is by way of a
> "raw-uefi" byhand-style object attached via dpkg-distaddfile, which of
> course wants to have a degree of automation.
> Here's a strawman patch to get a discussion started; I've written tests
> for the copier class, but the byhand script is entirely untested.
> The main thing I have not done in this patch is as follows.  In Ubuntu,
> we have no manual processing of byhand-style objects; any such object
> has to have entirely automatic processing.  This means that we have to
> defend against somebody getting upload rights for some relatively
> inconsequential package and promptly uploading a version of it that
> attaches UEFI malware which we'd then merrily sign with our key.  To do
> this, we arrange for any binaryful uploads with "raw-uefi" objects
> attached to hit an UNAPPROVED queue, which an ftpmaster then has to
> accept.  I gather Debian doesn't have an UNAPPROVED queue as such, but
> Mark suggested that it could just go through NEW.

Yeah, I mean, that's not going to add much more work. We always have a
flood of things in NEW, and with GRUB, we could just check out the diff
(might need to patch process-new for that) during NEW-time, and just get
an ACK there.

> I am a bit concerned about the idea that any grub2 upload could
> henceforth end up having a multi-day or multi-week turnaround.  There
> may not be any real way around this, but any thoughts would be welcome.

Yeah, well, it's a manual process. I can't commit to anything, but I
would go out of my way to respond to such uploads in a timely way.

> Maybe known boot loaders could be whitelisted; but then that means any
> DD could NMU grub2 to get their malware in. 

DDs are a shady bunch :)

> On the other hand the
> converse means that now an ftpmaster might have to do at least a cursory
> source review of all grub2 uploads, which might not exactly fill you
> with joy.

I don't hate it, myself.

> Comments appreciated.

+1 to the whole deal. I enjoy the thought of Debian supporting Secure
Boot. I eagerly await the day when we support it.

> [1] There's no real way around this on x86, since pretty much all SB
>     systems have to have the Microsoft key present for option ROMs and
>     the like, and images signed by multiple keys don't work reliably on
>     many firmware implementations seen in the wild.
> [2] See e.g. http://lwn.net/Articles/519618/
> Thanks,
> -- 
> Colin Watson                                       [cjwatson@ubuntu.com]


 .''`.  Paul Tagliamonte <paultag@debian.org>  |   Proud Debian Developer
: :'  : 4096R / 8F04 9AD8 2C92 066C 7352  D28A 7B58 5B30 807C 2A87
`. `'`  http://people.debian.org/~paultag
 `-     http://people.debian.org/~paultag/conduct-statement.txt

Attachment: signature.asc
Description: Digital signature

Reply to: