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

["Luis R. Rodriguez" <mcgrof@suse.com>]

On Wed, Jul 27, 2016 at 12:36:07PM -0400, James Bottomley wrote:
> On Wed, 2016-07-27 at 12:28 -0400, James Bottomley wrote:
> > 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.
> 
> As an aside to the aside, perhaps we want the .builtin_trusted_keys to
> be mutable up to the point the kernel finishes init and then immutable
> after.  That would allow us to update it from the initrd if the
> composition of the secure boot keys was in question.

Are you aware of other similar uses before ?

  Luis