Secure boot signing infrastructure - feedback request

[Ansgar Burchardt]

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?

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

Hmm, last I asked revocations weren't a concern for kernels with a valid
signature and known vulnerabilities that can be used to bypass the
secure boot foo either.

>> What human intervention are you wanting here?
>
> A human decides when processing the BYHAND queue whether this binary
> upload looks reasonable.

That's really not going to happen.  I don't want to manually process
packages.  I very strongly doubt the other ftp-masters want to either.

What should the human check anyway?  That someone signed the source
upload?  That someone (or something for buildds) signed the binary
upload?  That is already done automatically; looking at the source code
is unreasonable (and might not correspond to binaries anyway when you
consider evil uploads).

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

No, it doesn't.  dak only checks that a package claims to come from a
source package present in the archive; otherwise binNMUs would not work.
For an upload containing only byhand files not even that is checked.

Also we have the problem with "evil uploads" everywhere...  It doesn't
really matter if the kernel (with secure boot) is fine if userland is
not.

(And I'm not even going to start how everyone with upload permissions
can exploit buildds to upload arbitrary packages or insert bad code in
other, unrelated packages built on the same buildd.  Including the
secure boot signed packages.)

>> > On the other side... there is an FTP team objection with no documented
>> > explanation.

 - byhand files for security-master break the security-master ->
   ftp-master sync
 - The autobyhand scripts don't work for uploads that go to NEW.
 - byhand files are not that nice; I would rather not add more of them
 - byhand files aren't publish in the public archive, so harder to see
   what was actually signed.  Nothing enforces the binaries in the *.deb
   and the *.tar.gz are related after all.  Or that a *.deb is present.
 - Not clear how to publish signed binaries for the manual step in
   preparing uploads for the security archive.

I admit I don't like requiring access to a signing service on buildds
either.  It also makes it harder to trust the build process less in the
future (for example by moving it to a VM so it is restricted to do evil
stuff only the the current build, not having access to private keys and
removing access to network services).

Ansgar