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

[Petko M. <pe...@mi...>]

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.

> > Having just one key in .system_keyring is essentially like initializing ca_keys 
> > with a specific id, right?
> 
> If you've built your own kernel, the builtin key used to sign kernel
> modules could probably be used to sign other keys being loaded onto the
> IMA keyring.  In that scenario, then yes it would be the same thing.

OK.

> > The problem is that the system and owner trusted keyrings are both read-only, 
> > IOW it is impossible to load new certificates into them.  
> 
> I was definitely able to load keys onto the owner keyring, when the
> patches were posted.  Perhaps something has changed.  I'll have to take
> a look.   At the time, one of the problems was userspace could delete
> keyrings.  Check and see if you can delete the keyring from userspace.

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

As a 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.

> > These 'owner' certificates are used to further authenticate the IMA keys that go 
> > to .ima and nothing else.  Here is an example: company A is the system 
> > manufacturer (only A's cert is in the system trusted keyring), company B is the 
> > user.  B wants to be able to sign and run their own binaries on the said system. 
> > There are two options - send the stuff to A for signing and wait to get it back 
> > or ask A to sign B's certificate, which B will use to sign their objects 
> > locally.
> 
> The other option would be to sign company B's certificate with the private key 
> of the mini CA key stored in the MoK db.

Yep, either this or something similar is the most likely scenario.

> > Having their own trusted certificate allows B to do everything they need in a 
> > timely manner without going back and forth to A.  Things are getting even more 
> > complex if there is another simultaneous user of the same machine - company C.
> 
> They both can't own the system, can they?  Or does company B own the
> system, while company C is a tenant?

The latter, if there ever is company C.  We need to support this case if it ever 
comes to that.

> > The way i see it we have no other choice.  Please correct me if i am wrong.
> 
> If company C has root privileges, it can load its own key in the MoK db.
> Otherwise company B could load it for company C.  In that case, we could
> extend ca_keys to identify multiple keys. 

I am under the impression that MoK db is read-only and the keys are harvested 
from the corresponding UEFI variable(s) at boot, just like those in the kernel 
root directory at build time?


		Petko