Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]
Groups > linux.debian.kernel > #59399
| From | Helen Koike <helen.koike@collabora.com> |
|---|---|
| Newsgroups | linux.debian.kernel |
| Subject | Re: Secure boot signing infrastructure - feedback request |
| Date | 2017-11-15 14:50 +0100 |
| Message-ID | <uM6eJ-2ya-3@gated-at.bofh.it> (permalink) |
| References | (2 earlier) <uyJfZ-5Uo-9@gated-at.bofh.it> <uyKF3-74D-13@gated-at.bofh.it> <uzTPY-2RZ-21@gated-at.bofh.it> <uzTZT-34a-445@gated-at.bofh.it> <uGH7l-3XU-17@gated-at.bofh.it> |
| Organization | linux.* mail to news gateway |
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
Back to linux.debian.kernel | Previous | Next — Previous in thread | Next in thread | Find similar | Unroll thread
Secure boot signing infrastructure - feedback request Helen Koike <helen.koike@collabora.com> - 2017-10-05 20:30 +0200
Re: Secure boot signing infrastructure - feedback request Helen Koike <helen.koike@collabora.com> - 2017-10-09 03:20 +0200
Re: Secure boot signing infrastructure - feedback request Ben Hutchings <ben@decadent.org.uk> - 2017-10-09 15:10 +0200
Re: Secure boot signing infrastructure - feedback request Steve McIntyre <steve@einval.com> - 2017-10-09 18:40 +0200
Re: Secure boot signing infrastructure - feedback request Julien Cristau <jcristau@debian.org> - 2017-10-09 18:50 +0200
Re: Secure boot signing infrastructure - feedback request Ben Hutchings <ben@decadent.org.uk> - 2017-10-09 20:10 +0200
Re: Secure boot signing infrastructure - feedback request Ansgar Burchardt <ansgar@debian.org> - 2017-10-13 00:10 +0200
Re: Secure boot signing infrastructure - feedback request Helen Koike <helen.koike@collabora.com> - 2017-10-13 00:20 +0200
Re: Secure boot signing infrastructure - feedback request Steve McIntyre <steve@einval.com> - 2017-10-31 17:00 +0100
Re: Secure boot signing infrastructure - feedback request Helen Koike <helen.koike@collabora.com> - 2017-11-15 14:50 +0100
Re: Secure boot signing infrastructure - feedback request Ben Hutchings <ben@decadent.org.uk> - 2017-11-23 00:20 +0100
Re: Secure boot signing infrastructure - feedback request Steve McIntyre <steve@einval.com> - 2017-11-23 17:30 +0100
Re: Secure boot signing infrastructure - feedback request Ben Hutchings <ben@decadent.org.uk> - 2017-11-23 00:10 +0100
Re: Secure boot signing infrastructure - feedback request Ben Hutchings <ben@decadent.org.uk> - 2017-11-23 00:10 +0100
Re: Secure boot signing infrastructure - feedback request Steve McIntyre <steve@einval.com> - 2017-11-23 17:30 +0100
Re: Secure boot signing infrastructure - feedback request Ben Hutchings <ben@decadent.org.uk> - 2017-11-22 23:10 +0100
Re: Secure boot signing infrastructure - feedback request Tollef Fog Heen <tfheen@err.no> - 2017-11-24 21:00 +0100
Re: Secure boot signing infrastructure - feedback request Steve McIntyre <steve@einval.com> - 2017-10-13 00:50 +0200
Re: Secure boot signing infrastructure - feedback request Ben Hutchings <ben@decadent.org.uk> - 2017-11-22 23:20 +0100
csiph-web