Secure boot signing infrastructure - feedback request
Helen Koike
helen.koike at collabora.com
Wed Nov 15 13:18:20 UTC 2017
Hi,
On 10/31/2017 01:58 PM, Steve McIntyre wrote:
> 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?
>
I think a Sprint about Secure Boot would be great, we just need to make
sure that at least the people who disagree with one approach or the
other will be present.
@ftpmasters and @Ben, if you could reply if you would be willing to
attend it would be great, so we can start organizing it and work
together to find a good solution.
Thanks
Helen
More information about the Pkg-grub-devel
mailing list