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

Re: EFI in Debian

On Sat, 2012-07-07 at 08:46 -0600, Ansgar Burchardt wrote:
> Hi,
> Ben Hutchings <ben@decadent.org.uk> writes:
> > 2. Upstream kernel support: when booted in Secure Boot mode, Linux would
> > only load signed kernel modules and disable the various debug interfaces
> > that allow code injection.  I'm aware that David Howells, Matthew
> > Garrett and others are working on this.
> That makes dkms modules unusable when using secure boot.  I guess we
> would have to build binary packages for all supported kernel versions?

The Linux kernel hardly has a perfect security record, but signing code
that is too bad even for staging will be a quick route to blacklisting.
I would absolutely oppose signing out-of-tree modules with Debian keys.

> > 5. Key management policy.  Similar issues to archive signing keys, but
> > these keys also need to be available at build time.  (a) Should they be
> > held by package maintainers and/or the auto-builders for the relevant
> > architectures?  (b) sbuild and/or pbuilder will need to know how to
> > inject them into the build environment for the relevant packages.  (c)
> > How do we handle key replacement when exploitable code needs to be
> > blacklisted?
> Do these need to be available when building the kernel packages or would
> it be possible to have the signatures in a separate package?

That is possible... but the installation process would be tricky.

> The latter
> would allow moving the signing off the auto-builders and having either
> a human maintainer or a dedicated system do so instead (so the
> auto-builders would not need access to the keys).  It would also allow
> signing modules provided in the maintainer upload.

It would also help sites to sign with their own PK, if they want to take
full advantage of Secure Boot.


Ben Hutchings
When in doubt, use brute force. - Ken Thompson

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

Reply to: