Secure boot signing infrastructure - feedback request

[Steve McIntyre]

On Mon, Oct 09, 2017 at 07:00:14PM +0100, Ben Hutchings wrote:
>On Mon, 2017-10-09 at 17:38 +0100, Steve McIntyre wrote:
>> On Mon, Oct 09, 2017 at 02:01:15PM +0100, Ben Hutchings wrote:
>[...]
>> > 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.
>
>It's also audited - every upload is publicly logged, which makes it
>hard for an attacker to hide an evil upload.
>
>The archive is signed, rather than individual packages, and those
>signatures are valid for a limited period.  So if an evil upload is
>successful, we can replace it, warn users, and then by the time it's
>forgotten the signature will be invalid.
>
>A signing service would have to implement a separate audit mechanism. 
>And code signing can't be time limited so if we sign an evil upload
>we'll need to revoke it somehow.

Right, thanks for explaining. I understand your concerns much better
now.

>> What human intervention are you wanting here?
>
>A human decides when processing the BYHAND queue whether this binary
>upload looks reasonable.  If it's built from an NMU, I would hope this
>gets extra scrutiny (perhaps including a query to the maintainer). 
>(Ideally that would happen at the source upload stage for packages that
>get code-signed.  I'm not sure if that's possible to do.)

The plan for the ftpmaster route (as communicated to me) was *not*
necessarily going to need actual manual processing of the BYHAND queue
for bits needing signing. Is that something we can (should?)
legitimately expect - every signed package to get extra manual
checking by ftpteam?

>Also, dak checks that every binary upload corresponds to a source
>upload, so an evil upload will have to be either a source upload or a
>replacement of a binary upload.  It seems like the proposed signing
>service would allow an attacker that compromises a buildd to get code
>signed at any time, independently of a source upload.

True, yes. The *normal* flow would also see output going through dak
and validating the source-binary relationship, but a compromised
buildd could of course sidestep that, by simply not uploading the
results at all.

On the flip side, how far are we going to get if we can't trust the
buildds? Reproducibility helps, but only if the source uploader can
already generate matching builds for all the packages on all the
architectures we want to support.

>> 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.
>
>This mechanism already exists in dak, of course.

Nod.

-- 
Steve McIntyre, Cambridge, UK.                                steve at einval.com
  Armed with "Valor": "Centurion" represents quality of Discipline,
  Honor, Integrity and Loyalty. Now you don't have to be a Caesar to
  concord the digital world while feeling safe and proud.