Re: [Linux-ima-user] [RFC] IMA Root certificate hierarchy keyring

[Mimi Z. <zo...@li...>]

On Mon, 2015-05-18 at 15:42 +0300, Petko Manolov wrote:
> On 15-05-14 18:01:35, Mimi Zohar wrote:
> > On Thu, 2015-05-14 at 15:05 +0300, Petko Manolov wrote:
> > > 
> > > What do you mean by "brokenness"?
> > 
> > The CA trust model is broken.  Lets say A trusts B, and B trusts C, and
> > C trusts  X, Y, & Z.  That means that A not only trusts B, but also C
> > and everything that C trusts (X, Y, & Z).   There are a number of
> > articles about the problem.  Here's a recent example
> > https://www.schneier.com/blog/archives/2015/03/chinese_ca_issu.html.
> 
> Oh, this has always been broken.  The environment we're going to deploy the 
> system in is much more restricted.  It will seldom have more than a couple of 
> certificates, but we'd like to have some sort of hierarchy just in case.
> 
> The end users of this system are supposed to be well educated in terms of 
> cryptography technologies and security protocols.

Ok

> Patch number 4 (the one that introduces owner_keyring) does not seem to be 
> mainlined as of v4.0.4.

Up to now, "ca_keys" provided the necessary functionality without the
need for an additional keyring.  The use case scenario you described
seems to require an additional keyring.   As long as this new keyring is
not enabled by default, I don't have a problem with it.  The term
"root_ca" has too many connotations associated with it.  Instead of
calling the new keyring 'ima_root_ca_keyring' or 'owner_kerying',
consider using '.trusted_ca_keyring'  or '.ima_trusted_ca_keyring'. 

> As root i was able to revoke just about any keyring except for the 
> .system_keyring.  I guess this is due to KEY_USR_WRITE.  Maybe a special check 
> must be performed so trusted keyrings can't be revoked and/or removed.

Like the .system_keyring, userspace shouldn't be able to remove the .ima
keyring either.   Please ensure the new keyring can not be removed by
userspace either.

thanks,

Mimi