Secure boot signing infrastructure - feedback request

[Steve McIntyre]

On Mon, Oct 09, 2017 at 02:01:15PM +0100, Ben Hutchings wrote:
>On Thu, 2017-10-05 at 14:57 -0300, Helen Koike wrote:
>> Hello all,
>> 
>> As you probably already know, Debian doesn't support the Secure Boot
>> chain yet.
>> To support it we need to sign Grub and the Kernel with our key, so we
>> are discussing the best infrastructure for this workflow.
>> 
>> The first approach we had was to add a by-hand script in Dak as
>> described here
>> https://wiki.debian.org/SecureBoot#First_option:_by-hand_script_in_dak
>> But this option wasn't well received by the ftpteam
>
>I would like to know what the objection was.

I'll let the ftpteam people expand on that.

>> The second approach we have is to add some debhelper scripts (e.g
>> dh_sign...) that will access a signing service which will sign the
>> binaries with Debian's key.  We would use the dh_sign... helpers when
>> making an extra binary package. buildd would then publish the -signed
>> version of the package in the archives.
>> Please see a more detailed explanation here
>> https://wiki.debian.org/SecureBoot#Second_option:_use_buildd_.2B-_debhelper_instead_of_dak
>> A current known issue with this approach is the NEW queue: it requires
>> the maintainer to also upload binaries for an architecture on first
>> upload, and these binaries are not rebuilt by the buildd ( see
>> https://wiki.debian.org/SecureBoot#Issues ).
>
>It also makes all these packages unreproducible, which is a policy
>violation.

Surely *anything* with a signature is going to be unreproducible
directly, by definition. To check for reproducibility, you'll need to
strip the signatures. Or are you claiming something else?

There's two ways to solve this, that we came up with in discussion:

 * the dh_sign helpers will be configurable on the building machine -
   they can be set up to use whatever key setup is desired. That could
   be local on the machine, or a remote signing service, or simply a
   no-sign pass-through mode. That last mode could validate the
   reproducibility.

 * include a tool to reproducibly just strip the signatures on
   binaries

>It also appears to mean that buildds can get anything signed on demand
>with no human intervention at all, without all the checks that dak does
>on uploads.  This seems to be to substantially raise the risk of
>signing evil code and needing to revoke those signatures (or the
>signing key).

We spoke about this too. Source packages uploaded and eventually built
on the buildds already go through dak and wanna-build, for one.  We
have to trust that mechanism already. What human intervention are you
wanting here? We're also looking at a whitelist of specific packages
that the buildd and signing service will allow to be signed, to reduce
the potential attack surface.

>Plus the reliability issues you pointed out on the wiki.

Right - we're trying to consider the issues as we go.

>> I would like to know everyone's opinions about these approaches, if you
>> agree to go forward with the second approach described above and how do
>> we solve the NEW queue policy issue.
>
>So far as I can see, the second approach is difficult, risky,
>unreliable and leads to policy violations.
>
>On the other side... there is an FTP team objection with no documented
>explanation.

-- 
Steve McIntyre, Cambridge, UK.                                steve at einval.com
"We're the technical experts.  We were hired so that management could
 ignore our recommendations and tell us how to do our jobs."  -- Mike Andrews