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

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

On Wed, 2015-05-13 at 10:45 +0300, Petko Manolov wrote:
> 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.

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

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

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.

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

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

Mimi