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. -- Ben Hutchings When in doubt, use brute force. - Ken Thompson
Attachment:
signature.asc
Description: This is a digitally signed message part