[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Re: Where are we with SB? What's missing?

On Thu, 2018-10-11 at 16:58 +0100, Steve McIntyre wrote:
> On Sat, Oct 06, 2018 at 01:33:36PM +0200, Ansgar Burchardt wrote:
> > There are still two things I would like to look at:
> > 
> > Ben suggested adding an entry to the signing request to make sure we do
> > never create a trust chain from the production key to any non-
> > production key[1].  Though I wonder if the kernel really needs to have
> > an embedded key at all?  On Ubuntu it seems to use the same set of keys
> > already trusted by UEFI (including those enrolled by users).  This way
> > DKMS modules can be signed by end users (after creating and enrolling a
> > local signing key).
> Pass. Ben?

We don't currently have support for this in the kernel as it never
landed upstream.  I think we should add it if it's being maintained.

> > I would like to solve this before switching to production keys.
> > 
> >  [1] https://wiki.debian.org/SecureBoot#Describing_the_trust_chain
> > 
> > We still need to look how and when to publish the logs of what we
> > signed.  However we should make sure not to publish records for
> > security updates too early: when kernel modules build reproducible,
> > most shouldn't change during a security update and this would allow to
> > see which module is affected by undisclosed security issues (unless
> > modules include the kernel version if which case they all change; I
> > didn't check).

They include the release string, but that doesn't usually change.


> > The lazy way out would be to only publish logs with a 
> > month delay or so.
> > 
> > This shouldn't be a blocker though.
> Right.
> I have one more thing to mention. From talking to the core EFI folks,
> they'd also like us to shift to a newer version of shim before too
> long. It would be nice to do that before Buster release, But it's
> *really* not a blocker for us enabling things today.
Ben Hutchings
For every complex problem
there is a solution that is simple, neat, and wrong.

Attachment: signature.asc
Description: This is a digitally signed message part

Reply to: