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

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

On Thu, 2015-05-14 at 15:05 +0300, Petko Manolov wrote:
> On 15-05-13 13:52:34, Mimi Zohar wrote:
> > 
> > Versions 3 - 5 had two keyrings.  Refer to the fourth patch "KEYS:
> > define an owner trusted keyring" in the patchset.
> > http://marc.info/?l=linux-security-module&m=140181833100961&w=2
> 
> Thanks.

> > This intermediary keyring that you're introducing unfortunately perpetuates 
> > the x509 certificate chain brokenness, by introducing a level of transitive 
> > trust in IMA. The existing "ca_keys=id:xxxxxx" boot command line parameter 
> > intentionally limits the root CA to a specific key, preferably created by the 
> > machine owner.  Only this key will then be used to verify third party 
> > certificates.
> 
> 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.

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

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

> We need to be able to 
> import new certificates without restarting the machine to boot new kernel or 
> read UEFI variables.

By creating a local mini-CA and installing it's key on the system
keyring (eg. the MoK db), the system owner controls which software is
allowed to run on the system by controlling which keys are signed and
loaded onto the IMA keyring.  With the local mini-ca key, the system
owner can sign new certificates and load them on the IMA keyring.

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

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

> > Right, the original patches referred to this keyring as owner trusted, not 
> > root_ca trusted.
> 
> Giving proper names is not my strong side. :)

Me either.

Mimi