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

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

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"?

Having just one key in .system_keyring is essentially like initializing ca_keys 
with a specific id, right?

The problem is that the system and owner trusted keyrings are both read-only, 
IOW it is impossible to load new certificates into them.  We need to be able to 
import new certificates without restarting the machine to boot new kernel or 
read UEFI variables.

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.

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.  
The way i see it we have no other choice.  Please correct me if i am wrong.

> Right, the original patches referred to this keyring as owner trusted, not 
> root_ca trusted.

Giving proper names is not my strong side. :)


		Petko