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

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

On Wed, 2016-07-27 at 19:20 +0200, Luis R. Rodriguez wrote:
> 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 ?

Similar uses of what?

Runtime immutable but boot time mutable?  Yes, it's the UEFI variable
lock protocol.

Not wanting to put Microsoft keys in the immutable trusted keyring? No,
it was just a suspicion based on how I'd feel if my secure boot system
still had a MS key.

James