Date:	Wed, 13 Jan 2016 12:51:36 -0500
From:	Mimi Zohar <zohar@...ux.vnet.ibm.com>
To:	Petko Manolov <petkan@...-labs.com>
Cc:	David Howells <dhowells@...hat.com>,
	James Morris <jmorris@...ei.org>,
	linux-security-module@...r.kernel.org, keyrings@...r.kernel.org,
	linux-kernel@...r.kernel.org, mdb@...iper.net
Subject: Re: [PATCH] X.509: Partially revert patch to add validation against
 IMA MOK keyring

On Wed, 2016-01-13 at 18:31 +0200, Petko Manolov wrote:
> On 16-01-12 17:08:44, David Howells wrote:
> > Petko Manolov <petkan@...-labs.com> wrote:
> > 
> > > There is no need for .ima_mok if here is .mok, which should be system wide
> > > keyring.  I'm trying to say that once we have .mok (you're more than welcome
> > > to suggest better name) we'll get rid of .ima_mok.
> > 
> > If we really must have separate keyrings - and I still don't see that it's
> > necessary - then maybe:
> >
> > 	.builtin_trusted_keys (RO)
> > 	.secondarily_trusted_keys (RW).
> 
> Yep, that's the basic idea.

The "builtin_trusted_keys" is fine.  It would be
"secondary_trusted_keys".  This secondary keyring needs to be Kconfig
optional.

> > I'm not sure why it makes you any more uneasy than having .ima_mok at all. 
> > However, if it makes you able to sleep at night (;-)), and you're willing to 
> > accept modification of the trust model along the lines of the patchset I 
> > posted (which will need a couple of alterations) and move the new trust 
> > keyring and blacklist keyring to the core, then okay, we can do that.
> 
> I'll sleep much better once i grasp your entire patch-set, although it will 
> require some lack of sleep on my part. ;-)
> 
> I am also afraid these "couple of alternations" should be communicated to all 
> stakeholders (Mimi, for one), especially if we decide to make .ima_mok to be 
> system wide .secondarily_trusted_keys.  I volunteer to be excluded from the name 
> giving competition. :-)
> 
> It is also not clear to me how we'll move keys to the blacklist keyring.  They 
> should obviously be signed by CA in primary/secondary trusted keyring(s), the 
> permissions should be set correctly, but i somehow feel this is not enough.

> Mark, would you please comment on the above?
> 
> > > I don't mind linking in general as long as the permission check is 
> > > supplementary to the keys CA hierarchy verification.
> > 
> > Which it currently isn't really.  As things stand, the CA hierarchy 
> > verification takes place once at key creation and is assumed applicable to all 
> > trusted keyrings thereafter.  KEY_FLAG_TRUSTED_ONLY was only really supposed 
> > to apply to the system keyring.
> 
> I am not opposed to everything what you suggest.  Since we did that work in 
> parallel (your stuff and the IMA keyring additions) with no communication 
> between us, we ended up with broken IMA model.  I see three possibilities:
> 
>   - dump the IMA changes for this release (not happy about it);
> 
>   - try to quickly adapt the IMA system to your changes (not sure if it can be 
>     done easily and/or quickly) and do it properly for 4.6;
> 
>   - elevate .ima_mok/blacklist to system wide RW keyrings (we may miss the merge 
>     window);

I beg to differ.  The IMA model is not broken with the current patches
being upstreamed.  The basic concepts developed will continue to be
used, perhaps not directly by IMA.

David's proposal is a major redesign of keyrings and the system keyring
in particular.  It looks promising, but will need to be reviewed.

Mimi

Powered by blists - more mailing lists