Secure boot signing infrastructure - feedback request

[Steve McIntyre]

Nearly three weeks later with no responses. Let's see if we get things
moving...

On Wed, Oct 11, 2017 at 09:48:46PM -0300, Helen Koike wrote:
>
>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.

I think it's a fair summary, yes.

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

I *personally* believe that being able to remove the signatures and
compare binaries is fine for reproducibility purposes. Arguments
otherwise would help here.

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

ACK.

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

Right. Wanting to go the revocation route would depend on the
development of yet more new software features. But: this is not
something that any of the other SB-supporting distros seem to be
caring about so far so I don't think it's something we should have to
implement as a pre-requisite.

>* 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?

We've been discussing Secure Boot for ~5 years now, and I think it's
an important feature that we should support in Debian. Does anybody
here disagree with that?

Multiple people have spent time designing and implementing pieces of
the solution to make it work in Debian's infrastructure, but we've yet
to make any progress in actually *doing* it.

We've had a suggestion (and initial patches) to do this via
"autobyhand" scripts on ftp-master, but we've finally seen public
objections to that design from ftpmaster. Ben's hopes for that route
seem unrealistic too, in terms of manual processing and checking.

As a second option, in a discussion with Joerg (remotely) and Luke at
DebConf, we thrashed out what we thought was a reasonable alternate
solution to drive signing via the buildds instead. Ben has voiced some
concerns about the security of that path (extending the attack surface
for signed binaries) and reproducibility.

So, we're at an impasse. We've had multiple attempts to get this
going, with various subsets of this group discussing designs but not
*all* the interested parties at each point. We've seen (effective)
vetos of each of those designs, meaning we're stalled. Where do we go
from here? I appreciate that some folks might feel slighted that
they've been left out of some of the discussions. If so, sorry - that
was not intentional. :-( Can we put that behind us and work together
to make a workable solution please?

I propose a sprint to get things moving. I'm prepared to organise it,
and facilitate as much as I can. I recognise that not everybody might
be able to (or willing to) attend in person, but I don't think that
should be a barrier to constructive discussions. Thoughts?

-- 
Steve McIntyre, Cambridge, UK.                                steve at einval.com
Who needs computer imagery when you've got Brian Blessed?
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 833 bytes
Desc: not available
URL: <http://lists.alioth.debian.org/pipermail/pkg-grub-devel/attachments/20171031/edc5a0d2/attachment.sig>