linux-ima-user

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

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

On Tue, 2015-05-12 at 19:36 +0300, Petko Manolov wrote:
> On 15-05-12 19:00:58, Petko Manolov wrote:
> > 	Hi guys,
> > 
> > Please excuse the monolithic patch - it is small and meant for RFC only.

The size is fine.

> > The project i am currently working on requires dynamic add/revoke of both IMA 
> > keys and their respective signing certificates.  This requirement pivots around 
> > two things: machine uptime and achieving some sort of CA hierarchy.
> > 
> > The name is misleading but shows its primary use: .ima_root_ca_keyring - it is 
> > in fact system-wide keyring storing intermediate CA public keys, which are used 
> > to verify the actual IMA key's signature.
  
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.

> > .ima_root_ca_keyring allows the root user to dynamically add new certificate and 
> > signed IMA key to the system, mount new FS with properly signed objects and 
> > read/execute files off it without going through reboot cycle.  It also gives us 
> > the ability to import IMA keys signed by different entities/certificates, all 
> > having their root at a certificate in .system_keyring.

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

Mimi

> > The patch is tested and, as far as i can tell, does what it was designed for.  
> > Any comment would be greatly appreciated.
> > 
> > 
> > thanks,
> > Petko
> 
> Posting the patch again as a non-attachment.
> 
> 
> 		Petko
> 
> 
> ---
> 
> diff --git a/crypto/asymmetric_keys/x509_public_key.c b/crypto/asymmetric_keys/x509_public_key.c
> index a6c4203..83a0425 100644
> --- a/crypto/asymmetric_keys/x509_public_key.c
> +++ b/crypto/asymmetric_keys/x509_public_key.c
> @@ -281,6 +281,8 @@ static int x509_key_preparse(struct key_preparsed_payload *prep)
>  			goto error_free_cert;
>  	} else if (!prep->trusted) {
>  		ret = x509_validate_trust(cert, get_system_trusted_keyring());
> +		if (ret)
> +			ret = x509_validate_trust(cert, get_ima_root_ca_keyring());
>  		if (!ret)
>  			prep->trusted = 1;
>  	}
> diff --git a/include/keys/system_keyring.h b/include/keys/system_keyring.h
> index 72665eb..7a632e1 100644
> --- a/include/keys/system_keyring.h
> +++ b/include/keys/system_keyring.h
> @@ -28,4 +28,17 @@ static inline struct key *get_system_trusted_keyring(void)
>  }
>  #endif
> 
> +#ifdef CONFIG_IMA_ROOT_CA_KEYRING
> +extern struct key *ima_root_ca_keyring;
> +static inline struct key *get_ima_root_ca_keyring(void)
> +{
> +	return ima_root_ca_keyring;
> +}
> +#else
> +static inline struct key *get_ima_root_ca_keyring(void)
> +{
> +	return NULL;
> +}
> +#endif /* CONFIG_IMA_ROOT_CA_KEYRING */
> +
>  #endif /* _KEYS_SYSTEM_KEYRING_H */
> diff --git a/security/integrity/ima/Kconfig b/security/integrity/ima/Kconfig
> index df30334..f859451 100644
> --- a/security/integrity/ima/Kconfig
> +++ b/security/integrity/ima/Kconfig
> @@ -131,6 +131,15 @@ config IMA_TRUSTED_KEYRING
>  	   This option requires that all keys added to the .ima
>  	   keyring be signed by a key on the system trusted keyring.
> 
> +config IMA_ROOT_CA_KEYRING
> +	bool "Create IMA Root CA keyring"
> +	depends on IMA_TRUSTED_KEYRING
> +	default y
> +	help
> +	   This option creates IMA Root CA keyring.  All keys in it must be
> +	   signed either by a key in the .system keyring or one which is already
> +	   in .ima_root_ca_keyring.
> +
>  config IMA_LOAD_X509
>  	bool "Load X509 certificate onto the '.ima' trusted keyring"
>  	depends on IMA_TRUSTED_KEYRING
> diff --git a/security/integrity/ima/Makefile b/security/integrity/ima/Makefile
> index d79263d..b2f9aa0 100644
> --- a/security/integrity/ima/Makefile
> +++ b/security/integrity/ima/Makefile
> @@ -8,3 +8,4 @@ obj-$(CONFIG_IMA) += ima.o
>  ima-y := ima_fs.o ima_queue.o ima_init.o ima_main.o ima_crypto.o ima_api.o \
>  	 ima_policy.o ima_template.o ima_template_lib.o
>  ima-$(CONFIG_IMA_APPRAISE) += ima_appraise.o
> +obj-$(CONFIG_IMA_ROOT_CA_KEYRING) += ima_root_ca.o
> diff --git a/security/integrity/ima/ima_root_ca.c b/security/integrity/ima/ima_root_ca.c
> new file mode 100644
> index 0000000..95d2526
> --- /dev/null
> +++ b/security/integrity/ima/ima_root_ca.c
> @@ -0,0 +1,41 @@
> +/*
> + * This program is free software; you can redistribute it and/or
> + * modify it under the terms of the GNU General Public License as
> + * published by the Free Software Foundation, version 2 of the
> + * License.
> + *
> + */
> +
> +#include <linux/export.h>
> +#include <linux/kernel.h>
> +#include <linux/sched.h>
> +#include <linux/cred.h>
> +#include <linux/err.h>
> +#include <linux/module.h>
> +#include <keys/asymmetric-type.h>
> +
> +MODULE_LICENSE("GPL");
> +
> +struct key *ima_root_ca_keyring = NULL;
> +EXPORT_SYMBOL_GPL(ima_root_ca_keyring);
> +
> +/*
> + * Allocate the IMA Root CA keyring
> + */
> +__init int ima_root_ca_init(void)
> +{
> +	pr_notice("Initialise IMA Root CA keyring.\n");
> +
> +	ima_root_ca_keyring = keyring_alloc(".ima_root_ca",
> +			      KUIDT_INIT(0), KGIDT_INIT(0), current_cred(),
> +			      (KEY_POS_ALL & ~KEY_POS_SETATTR) |
> +			      KEY_USR_VIEW | KEY_USR_READ |
> +			      KEY_USR_WRITE | KEY_USR_SEARCH,
> +			      KEY_ALLOC_NOT_IN_QUOTA, NULL);
> +	if (IS_ERR(ima_root_ca_keyring))
> +		panic("Can't allocate IMA Root CA keyring.");
> +	set_bit(KEY_FLAG_TRUSTED_ONLY, &ima_root_ca_keyring->flags);
> +	return 0;
> +}
> +
> +module_init(ima_root_ca_init);
> 
> --
> To unsubscribe from this list: send the line "unsubscribe linux-security-module" in
> the body of a message to maj...@vg...
> More majordomo info at  http://vger.kernel.org/majordomo-info.html
> 

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

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

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

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

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

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

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

On Mon, 2015-05-18 at 15:42 +0300, Petko Manolov wrote:
> 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.

Ok

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

Up to now, "ca_keys" provided the necessary functionality without the
need for an additional keyring.  The use case scenario you described
seems to require an additional keyring.   As long as this new keyring is
not enabled by default, I don't have a problem with it.  The term
"root_ca" has too many connotations associated with it.  Instead of
calling the new keyring 'ima_root_ca_keyring' or 'owner_kerying',
consider using '.trusted_ca_keyring'  or '.ima_trusted_ca_keyring'. 

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

Like the .system_keyring, userspace shouldn't be able to remove the .ima
keyring either.   Please ensure the new keyring can not be removed by
userspace either.

thanks,

Mimi