Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]

Groups > linux.debian.kernel > #59149

Re: Secure boot signing infrastructure - feedback request

Show all headers | View raw

[Multipart message — attachments visible in raw view] - view raw

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.

> 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.)

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.

> 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.

Ben.

> > 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.
> 
> 
-- 
Ben Hutchings
Humour is the best antidote to reality.

Back to linux.debian.kernel | Previous | Next — Previous in thread | Next in thread | Find similar | Unroll thread

Thread

Secure boot signing infrastructure - feedback request Helen Koike <helen.koike@collabora.com> - 2017-10-05 20:30 +0200
  Re: Secure boot signing infrastructure - feedback request Helen Koike <helen.koike@collabora.com> - 2017-10-09 03:20 +0200
  Re: Secure boot signing infrastructure - feedback request Ben Hutchings <ben@decadent.org.uk> - 2017-10-09 15:10 +0200
    Re: Secure boot signing infrastructure - feedback request Steve McIntyre <steve@einval.com> - 2017-10-09 18:40 +0200
      Re: Secure boot signing infrastructure - feedback request Julien Cristau <jcristau@debian.org> - 2017-10-09 18:50 +0200
      Re: Secure boot signing infrastructure - feedback request Ben Hutchings <ben@decadent.org.uk> - 2017-10-09 20:10 +0200
        Re: Secure boot signing infrastructure - feedback request Ansgar Burchardt <ansgar@debian.org> - 2017-10-13 00:10 +0200
          Re: Secure boot signing infrastructure - feedback request Helen Koike <helen.koike@collabora.com> - 2017-10-13 00:20 +0200
            Re: Secure boot signing infrastructure - feedback request Steve McIntyre <steve@einval.com> - 2017-10-31 17:00 +0100
              Re: Secure boot signing infrastructure - feedback request Helen Koike <helen.koike@collabora.com> - 2017-11-15 14:50 +0100
                Re: Secure boot signing infrastructure - feedback request Ben Hutchings <ben@decadent.org.uk> - 2017-11-23 00:20 +0100
                Re: Secure boot signing infrastructure - feedback request Steve McIntyre <steve@einval.com> - 2017-11-23 17:30 +0100
              Re: Secure boot signing infrastructure - feedback request Ben Hutchings <ben@decadent.org.uk> - 2017-11-23 00:10 +0100
            Re: Secure boot signing infrastructure - feedback request Ben Hutchings <ben@decadent.org.uk> - 2017-11-23 00:10 +0100
              Re: Secure boot signing infrastructure - feedback request Steve McIntyre <steve@einval.com> - 2017-11-23 17:30 +0100
          Re: Secure boot signing infrastructure - feedback request Ben Hutchings <ben@decadent.org.uk> - 2017-11-22 23:10 +0100
            Re: Secure boot signing infrastructure - feedback request Tollef Fog Heen <tfheen@err.no> - 2017-11-24 21:00 +0100
        Re: Secure boot signing infrastructure - feedback request Steve McIntyre <steve@einval.com> - 2017-10-13 00:50 +0200
          Re: Secure boot signing infrastructure - feedback request Ben Hutchings <ben@decadent.org.uk> - 2017-11-22 23:20 +0100

csiph-web