[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Re: Secure boot signing infrastructure - feedback request



]] Ben Hutchings 

(Sorry for the massive Cc list, it'd be nicer if this could all just go
to -efi, but I don't know if everybody is subscribed to that list, so…)

> Sorry for taking so long to respond to this.
> 
> On Tue, 2017-10-10 at 20:36 +0200, Ansgar Burchardt wrote:
> > Ben Hutchings writes:
> > > 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.
> > 
> > Does anyone ever look at the upload history of buildds and audits them?
> 
> I don't know.  But as I understand it, nation-state attackers generally
> don't like to leave traces, so public logs can be a valuable deterrent.

We can easily make the signing logs public too, possibly with some sort
of time delay mechanism if needed for handling of embargoed security.

Also, while we don't need to solve it (yet), it would be nice if the
proposed solution we go for is able to solve the case of signing all
binaries in the archive (or at least don't make it impossible to do), if
we decide to do something like Matthew talks about in
https://debconf17.debconf.org/talks/174/ .

Cheers,
-- 
Tollef Fog Heen
UNIX is user friendly, it's just picky about who its friends are


Reply to: