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

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

On 15-05-12 14:55:35, Mimi Zohar wrote:
>
> The original trusted keys patch set defined two separate keyrings.  One for 
> the keys used for verifying the IMA certificate and another for the IMA keys 
> themselves.  Until a use case was defined, only the trusted IMA keyring was 
> upstreamed.  The "ca_keys=" boot command line option was defined to limit the 
> system keyring to either the builtin keys or a specific key.

I'm relatively new to the game so please send a pointer to the original patch.

> Keys can be added to the IMA keyring without rebooting the system.  Why the 
> need for the additional keyring?

The system we're building has a bunch of requirements in terms of security - use 
signed keys only, all immutable files must be signed, certificates have lifespan 
of one year, etc.

On the other side third parties should be able to easily run their own software 
without rebooting the machine to introduce their own certificates.  Uptime is 
extremely important in this case.

Since .system_keyring is hardcoded and read-only it is impossible to import new 
certificates.  Adding intermediate keyring (which is read-write) to keep these 
third party, short-lived certificates nicely solves the above requirements.

The architecture typically look like this:


Root_CA (.system_keyring) ---> Cert_A (.ima_root_ca) ---> Key_A (.ima)
                           |
                           +-> Cert_B (.ima_root_ca) ---> Key_B (.ima)
                           |
                           |-> Cert_C (.ima_root_ca) ---> Key_C (.ima)

Root_CA has long life-span and its replacement requires new kernel/initramfs.  
These events should be very rare.  Cert_[A..C] must be signed by Root_CA's 
private key, but are expendable.  If Key_[A..C] private key get compromised or 
expire it may be revoked and replaced with another one without system reboot.

Intermediate certificates gives third parties flexibility to build their own 
hierarchy without bothering to go to the vendor to sign every bugfix.

I admit the name .ima_root_ca_keyring is technically incorrect as it is in the 
search path to all users of trusted system keyring.  However, creating 
IMA-specific intermediate keyring will require changing a lot more code than i 
feel comfortable with.  As it is impossible for unsigned certificate to land on 
.ima_root_ca_keyring i think this is not a security issue.


cheers,
Petko