Re: [Ksummit-discuss] Last minute nominations: mcgrof and toshi

[James Bottomley <James.Bottomley@HansenPartnership.com>]

On Wed, 2016-07-27 at 17:14 +0100, David Howells wrote:
> James Bottomley <James.Bottomley@HansenPartnership.com> wrote:
> 
> >    1. Population and update policy: How should we populate the default
> >       keyrings and revocation lists?  Should we have a built in list of
> >       absolute trust that can never be added to? I think the current
> >       default here is OK: it's populate with the kernel built in keys and
> >       nothing else.  If userspace wants to populate with, say, the secure
> >       boot keys, then it can do so from init.  An issue here is the
> >       Microsoft signing key, which most Linux people have but which they
> >       wouldn't necessarily consider to be a source of absolute trust. 
> >        However, third party driver vendors would like a way to get their
> >       key trusted by the kernel so they can easily supply modules (This
> >       isn't a binary module issue: the code is usually GPL, but the
> >       vendors would like to supply updates asynchronously to the distro
> >       release cycle).  We can say their key should be added as part of the
> >       rpm that installs the module, but do users really want this key
> >       adding to the default keyring to be trusted for non-module
> >       operations?
> 
> I have patches that allow the UEFI key and blacklist databases to add to the
> kernel keyrings during boot.
> 
> We don't want to permit loading a key from a file once the kernel is booted
> unless that key is signed by a key already in the keyrings.

This is a policy discussion we should have.  If you populate the
immutable .builtin_trusted_keys keyring with the secure boot keys, most
people will end up with a Microsoft key in their keyring (and possibly
even some random motherboard vendor ODM key) which they can't remove. 
 I thought the idea was to use the .secondary_trusted_keys keyring
which is mutable?  That way we can have policy in userspace select
which secure boot keys we might like to trust.

James