Re: UEFI Secure Boot - the plan for stretch
On Tue, Apr 05, 2016 at 03:36:01AM +0100, Ben Hutchings wrote:
>This should all be tracked in the BTS, so I started work on that (as
>you've probably seen).
>
>There is a tracking bug, #820036, which depends on all the others.
Cool.
>On Fri, 2016-04-01 at 14:35 +0100, Steve McIntyre wrote:
>[...]
>> 1. Generate a key and an EV code-signing cert, submit to Microsoft
>> ==================================================================
>>
>> This needs an RSA 2048 key. The process: we generate the key and the
>> self-signed certificate of the correct form, which is embedded in the
>> shim package that is then submitted to Microsoft. The signing request
>> requires obtaining an EV code-signing cert, and then this has to be
>> uploaded via Windows to Microsoft.
>>
>> Tollef was organising an HSM (Yubikey $thing) to make this more
>> secure. Exact details on key management are yet TBD - we had
>> discussions about an N-of-M keyholder scheme similar-ish to what
>> Ubuntu do.
>
>Does this require a bug report?
>
>> Steve Langasek to include the public key and cert in a shim package
>> for Debian, upload it and get it in the archive.
>>
>> Whoever controls the EV cert extracts the shim binary, puts it into a
>> cab, signs that with the EV cert and uploads the result.
>>
>> 2. dak changes to support upload and signing of EFI executables
>> ===============================================================
>>
>> Colin pointed at the code in launchpad as inspiration:
>>
>> https://git.launchpad.net/launchpad/tree/lib/lp/archivepublisher/uefi.py
>> https://git.launchpad.net/launchpad/tree/lib/lp/archivepublisher/tests/test_uefi.py
>>
>> and gave us a WIP dak patch. Luke (was?) volunteered to investigate
>> the dak work.
>
>Needs a bug report against dak and/or ftp.debian.org.
#821051 against ftp.d.o
>> 3. Prepare and upload a package of the 'shim' EFI boot loader
>> =============================================================
>>
>> This will embed our own set of public keys (corresponding to those
>> used by dak) and can load any other EFI executable signed by one of
>> them. Later, there will be a additional shim-signed package
>> containing the same executable with a Microsoft signature. (This
>> costs money and takes several days, but shim should require only very
>> infrequent changes.)
>>
>> Steve Langasek said he was happy to do this once we've got the rest of
>> the process started and we have a certificate ready to embed.
>
>Opened #820052.
>
>> 4. Updates for other core packages to add signed versions
>> =========================================================
>>
>> Once we have our key ready and dak support added, we'll be able to
>> upload things and get them signed automatically to create $foo-signed
>> packages. Expected packages here:
>>
>> * grub2
>
>Opened #820050.
>
>> * linux
>
>Opened #820006 (ITP) and #820008 (changes to linux).
>
>> * fwupdate
Mario added #820124, as he said.
>Someone who understands this should open an ITP or RFP.
>
>> * ???
>
>It seems we will have to distribute detached module signatures to
>maintain reproducibility and avoid duplication, so kmod, initramfs-
>tools and dracut all need to handle those. I've written the patches
>for kmod (#820010) and initramfs-tools (#820037), and it should be easy
>to support them in dracut (#820041).
*nod* Nothing else comes to mind just yet; we can add more as we get
requests.
>> 5. Minor tweaks to other places to make use of the signed packages
>> ==================================================================
>>
>> * d-i
>
>Opened #820038 against kernel-wedge, but more changes are needed in the
>debian-installer build scripts.
Opened #821053
>> * debian-cd
#821054
>> * debian-live
#821055 against live-wrapper for now
--
Steve McIntyre, Cambridge, UK. steve@einval.com
"I suspect most samba developers are already technically insane... Of
course, since many of them are Australians, you can't tell." -- Linus Torvalds
Reply to: