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] Cheers, Paul -- .''`. 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