Secure boot signing infrastructure - feedback request

[Helen Koike]

On 2017-10-10 03:36 PM, 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?
> 
>> 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
> 
> _______________________________________________
> Pkg-grub-devel mailing list
> Pkg-grub-devel at lists.alioth.debian.org
> http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/pkg-grub-devel
> 

I did a summary about the current discussion here:
https://wiki.debian.org/SecureBoot#Wrap-up_of_the_discussions_so_far
Feel free to edit this wiki or let me know if I forgot something.

Questions:
* About item 2.1. (reproducible builds), if we strip the signatures from
the binaries before doing the comparison is the reproducible build
criteria acceptable? Can we just strip the signatures and if the result
is the same we consider it reproducible? Or is changing the criteria ok?

* About item 2.2. Would it be ok if we just have a easy revoke mechanism?
In Shim there is already a MokListX (a blacklist of keys or binary
hashes), but the current way to update this list is if the user has
physical access to the machine, but I was talking with the Shim upstream
maintainer and we agreed that we could implement a solution where we
could feed a blacklist to shim, and if this list is signed by the
vendor_cert (aka Debian's key in our case), and if it is a newer version
of the list, shim would update MokListX without requiring user
intervention (it would be an equivalent to KEK for UEFI)
Is this solution acceptable? If we have an easy way to revoke, then we
can easily undo an attacker's work. We can sign everything automatically
(if the package is in a whitelist) without the need for the ftp masters
to review each upload manually.

* Item 2.4 seems the strongest argument to me against the buildd
approach, but the byhand approach seems to complicated, or we need to
reformulate it, any suggestions?

LN Koike