[RFC 0/1] ima/evm: signature verification support using asymmetric keys

[RFC 0/1] ima/evm: signature verification support using asymmetric keys

[Dmitry Kasatkin]

Asymmetric keys were introduced in linux-3.7 to verify the signature on signed
kernel modules.  The asymmetric keys infrastructure abstracts the signature
verification from the crypto details.  This patch adds IMA/EVM signature
verification using asymmetric keys.  Support for additional signature
verification methods can now be delegated to the asymmetric key infrastructure.

Although the module signature header and the IMA/EVM signature header could
use the same header format, to minimize the signature length and save space
in the extended attribute, the IMA/EVM header format is different than the
module signature header.  The main difference is that the key identifier is
a sha1[12 - 19] hash of the key modulus and exponent and similar to the current
implementation. The only purpose is to identify corresponding key in the kernel
keyring. ima-evm-utils was updated to support the new signature format.

BR,
Dmitry

Dmitry Kasatkin (1):
  ima: digital signature verification using asymmetric keys

 security/integrity/Kconfig  |   12 +++++
 security/integrity/digsig.c |  103 ++++++++++++++++++++++++++++++++++++++++++-
 2 files changed, 114 insertions(+), 1 deletion(-)

-- 
1.7.10.4

[RFC 1/1] ima: digital signature verification using asymmetric keys

[Dmitry Kasatkin]

Asymmetric keys were introduced in linux-3.7 to verify the signature on
signed kernel modules.  The asymmetric keys infrastructure abstracts the
signature verification from the crypto details.  This patch adds IMA/EVM
signature verification using asymmetric keys.  Support for additional
signature verification methods can now be delegated to the asymmetric
key infrastructure.

Signed-off-by: Dmitry Kasatkin <dmitry.kasatkin@intel.com>
---
 security/integrity/Kconfig  |   12 +++++
 security/integrity/digsig.c |  103 ++++++++++++++++++++++++++++++++++++++++++-
 2 files changed, 114 insertions(+), 1 deletion(-)

diff --git a/security/integrity/Kconfig b/security/integrity/Kconfig
index 5bd1cc1..19c4187 100644
--- a/security/integrity/Kconfig
+++ b/security/integrity/Kconfig
@@ -17,5 +17,17 @@ config INTEGRITY_SIGNATURE
 	  This is useful for evm and module keyrings, when keys are
 	  usually only added from initramfs.
 
+config INTEGRITY_ASYMMETRIC_KEYS
+	boolean "Digital signature verification using asymmetric keys"
+	depends on INTEGRITY_SIGNATURE
+	default n
+        select ASYMMETRIC_KEY_TYPE
+        select ASYMMETRIC_PUBLIC_KEY_SUBTYPE
+        select PUBLIC_KEY_ALGO_RSA
+        select X509_CERTIFICATE_PARSER
+	help
+	  This option enables digital signature verification support
+	  using asymmetric keys.
+
 source security/integrity/ima/Kconfig
 source security/integrity/evm/Kconfig
diff --git a/security/integrity/digsig.c b/security/integrity/digsig.c
index 2dc167d..1896537 100644
--- a/security/integrity/digsig.c
+++ b/security/integrity/digsig.c
@@ -15,10 +15,22 @@
 #include <linux/err.h>
 #include <linux/rbtree.h>
 #include <linux/key-type.h>
+#include <crypto/public_key.h>
+#include <keys/asymmetric-type.h>
 #include <linux/digsig.h>
 
 #include "integrity.h"
 
+/*
+ * signature format v2 - for using with asymmetric keys
+ */
+struct signature_v2_hdr {
+	uint8_t version;	/* signature format version */
+	uint8_t	hash_algo;	/* Digest algorithm [enum pkey_hash_algo] */
+	uint8_t keyid[8];	/* IMA key identifier - not X509/PGP specific*/
+	uint8_t payload[0];	/* signature payload */
+} __packed;
+
 static struct key *keyring[INTEGRITY_KEYRING_MAX];
 
 static const char *keyring_name[INTEGRITY_KEYRING_MAX] = {
@@ -27,6 +39,91 @@ static const char *keyring_name[INTEGRITY_KEYRING_MAX] = {
 	"_ima",
 };
 
+#ifdef CONFIG_INTEGRITY_ASYMMETRIC_KEYS
+
+/*
+ * Request an asymmetric key.
+ */
+static struct key *request_asymmetric_key(struct key *keyring, uint8_t *keyid)
+{
+	struct key *key;
+	char name[20];
+
+	sprintf(name, "%llX", __be64_to_cpup((uint64_t *)keyid));
+
+	pr_debug("key search: \"%s\"\n", name);
+
+	if (keyring) {
+		/* search in specific keyring */
+		key_ref_t kref;
+		kref = keyring_search(make_key_ref(keyring, 1),
+				      &key_type_asymmetric, name);
+		if (IS_ERR(kref))
+			key = ERR_CAST(kref);
+		else
+			key = key_ref_to_ptr(kref);
+	} else {
+		key = request_key(&key_type_asymmetric, name, NULL);
+	}
+
+	if (IS_ERR(key)) {
+		pr_warn("Request for unknown key '%s' err %ld\n",
+			name, PTR_ERR(key));
+		switch (PTR_ERR(key)) {
+			/* Hide some search errors */
+		case -EACCES:
+		case -ENOTDIR:
+		case -EAGAIN:
+			return ERR_PTR(-ENOKEY);
+		default:
+			return key;
+		}
+	}
+
+	pr_debug("%s() = 0 [%x]\n", __func__, key_serial(key));
+
+	return key;
+}
+
+static int asymmetric_verify(struct key *keyring, const char *sig,
+			     size_t siglen, const char *data, int datalen)
+{
+	struct public_key_signature pks;
+	struct signature_v2_hdr *hdr = (struct signature_v2_hdr *)sig;
+	struct key *key;
+	int ret = -ENOMEM;
+
+	if (siglen <= sizeof(*hdr))
+		return -EBADMSG;
+
+	siglen -= sizeof(*hdr);
+
+	if (hdr->hash_algo >= PKEY_HASH__LAST)
+		return -ENOPKG;
+
+	key = request_asymmetric_key(keyring, hdr->keyid);
+	if (IS_ERR(key))
+		return PTR_ERR(key);
+
+	memset(&pks, 0, sizeof(pks));
+
+	pks.pkey_hash_algo = hdr->hash_algo;
+	pks.digest = (u8 *)data;
+	pks.digest_size = datalen;
+	pks.nr_mpi = 1;
+	pks.rsa.s = mpi_read_from_buffer(hdr->payload, &siglen);
+
+	if (pks.rsa.s)
+		ret = verify_signature(key, &pks);
+
+	mpi_free(pks.rsa.s);
+	key_put(key);
+	pr_debug("%s() = %d\n", __func__, ret);
+	return ret;
+}
+
+#endif /* CONFIG_INTEGRITY_ASYMMETRIC_KEYS */
+
 int integrity_digsig_verify(const unsigned int id, const char *sig, int siglen,
 					const char *digest, int digestlen)
 {
@@ -43,6 +140,10 @@ int integrity_digsig_verify(const unsigned int id, const char *sig, int siglen,
 			return err;
 		}
 	}
-
+#ifdef CONFIG_INTEGRITY_ASYMMETRIC_KEYS
+	if (sig[0] == 2)
+		return asymmetric_verify(keyring[id], sig, siglen,
+					 digest, digestlen);
+#endif
 	return digsig_verify(keyring[id], sig, siglen, digest, digestlen);
 }
-- 
1.7.10.4

Re: [RFC 1/1] ima: digital signature verification using asymmetric keys

[Mimi Zohar]

On Tue, 2013-01-15 at 12:34 +0200, Dmitry Kasatkin wrote:
> Asymmetric keys were introduced in linux-3.7 to verify the signature on
> signed kernel modules.  The asymmetric keys infrastructure abstracts the
> signature verification from the crypto details.  This patch adds IMA/EVM
> signature verification using asymmetric keys.  Support for additional
> signature verification methods can now be delegated to the asymmetric
> key infrastructure.
> 
> Signed-off-by: Dmitry Kasatkin <dmitry.kasatkin@intel.com>
> ---
>  security/integrity/Kconfig  |   12 +++++
>  security/integrity/digsig.c |  103 ++++++++++++++++++++++++++++++++++++++++++-
>  2 files changed, 114 insertions(+), 1 deletion(-)
> 
> diff --git a/security/integrity/Kconfig b/security/integrity/Kconfig
> index 5bd1cc1..19c4187 100644
> --- a/security/integrity/Kconfig
> +++ b/security/integrity/Kconfig
> @@ -17,5 +17,17 @@ config INTEGRITY_SIGNATURE
>  	  This is useful for evm and module keyrings, when keys are
>  	  usually only added from initramfs.
> 
> +config INTEGRITY_ASYMMETRIC_KEYS
> +	boolean "Digital signature verification using asymmetric keys"
> +	depends on INTEGRITY_SIGNATURE
> +	default n
> +        select ASYMMETRIC_KEY_TYPE
> +        select ASYMMETRIC_PUBLIC_KEY_SUBTYPE
> +        select PUBLIC_KEY_ALGO_RSA
> +        select X509_CERTIFICATE_PARSER
> +	help
> +	  This option enables digital signature verification support
> +	  using asymmetric keys.
> +
>  source security/integrity/ima/Kconfig
>  source security/integrity/evm/Kconfig
> diff --git a/security/integrity/digsig.c b/security/integrity/digsig.c
> index 2dc167d..1896537 100644
> --- a/security/integrity/digsig.c
> +++ b/security/integrity/digsig.c
> @@ -15,10 +15,22 @@
>  #include <linux/err.h>
>  #include <linux/rbtree.h>
>  #include <linux/key-type.h>
> +#include <crypto/public_key.h>
> +#include <keys/asymmetric-type.h>
>  #include <linux/digsig.h>
> 
>  #include "integrity.h"
> 
> +/*
> + * signature format v2 - for using with asymmetric keys
> + */
> +struct signature_v2_hdr {
> +	uint8_t version;	/* signature format version */
> +	uint8_t	hash_algo;	/* Digest algorithm [enum pkey_hash_algo] */
> +	uint8_t keyid[8];	/* IMA key identifier - not X509/PGP specific*/
> +	uint8_t payload[0];	/* signature payload */
> +} __packed;
> +
>  static struct key *keyring[INTEGRITY_KEYRING_MAX];
> 
>  static const char *keyring_name[INTEGRITY_KEYRING_MAX] = {
> @@ -27,6 +39,91 @@ static const char *keyring_name[INTEGRITY_KEYRING_MAX] = {
>  	"_ima",
>  };
> 
> +#ifdef CONFIG_INTEGRITY_ASYMMETRIC_KEYS
> +
> +/*
> + * Request an asymmetric key.
> + */
> +static struct key *request_asymmetric_key(struct key *keyring, uint8_t *keyid)
> +{
> +	struct key *key;
> +	char name[20];
> +
> +	sprintf(name, "%llX", __be64_to_cpup((uint64_t *)keyid));
> +
> +	pr_debug("key search: \"%s\"\n", name);
> +
> +	if (keyring) {
> +		/* search in specific keyring */
> +		key_ref_t kref;
> +		kref = keyring_search(make_key_ref(keyring, 1),
> +				      &key_type_asymmetric, name);
> +		if (IS_ERR(kref))
> +			key = ERR_CAST(kref);
> +		else
> +			key = key_ref_to_ptr(kref);
> +	} else {
> +		key = request_key(&key_type_asymmetric, name, NULL);
> +	}
> +
> +	if (IS_ERR(key)) {
> +		pr_warn("Request for unknown key '%s' err %ld\n",
> +			name, PTR_ERR(key));
> +		switch (PTR_ERR(key)) {
> +			/* Hide some search errors */
> +		case -EACCES:
> +		case -ENOTDIR:
> +		case -EAGAIN:
> +			return ERR_PTR(-ENOKEY);
> +		default:
> +			return key;
> +		}
> +	}
> +
> +	pr_debug("%s() = 0 [%x]\n", __func__, key_serial(key));
> +
> +	return key;
> +}
> +
> +static int asymmetric_verify(struct key *keyring, const char *sig,
> +			     size_t siglen, const char *data, int datalen)
> +{
> +	struct public_key_signature pks;
> +	struct signature_v2_hdr *hdr = (struct signature_v2_hdr *)sig;
> +	struct key *key;
> +	int ret = -ENOMEM;
> +
> +	if (siglen <= sizeof(*hdr))
> +		return -EBADMSG;
> +
> +	siglen -= sizeof(*hdr);
> +
> +	if (hdr->hash_algo >= PKEY_HASH__LAST)
> +		return -ENOPKG;
> +
> +	key = request_asymmetric_key(keyring, hdr->keyid);
> +	if (IS_ERR(key))
> +		return PTR_ERR(key);
> +
> +	memset(&pks, 0, sizeof(pks));
> +
> +	pks.pkey_hash_algo = hdr->hash_algo;
> +	pks.digest = (u8 *)data;
> +	pks.digest_size = datalen;
> +	pks.nr_mpi = 1;
> +	pks.rsa.s = mpi_read_from_buffer(hdr->payload, &siglen);
> +
> +	if (pks.rsa.s)
> +		ret = verify_signature(key, &pks);
> +
> +	mpi_free(pks.rsa.s);
> +	key_put(key);
> +	pr_debug("%s() = %d\n", __func__, ret);
> +	return ret;
> +}
> +
> +#endif /* CONFIG_INTEGRITY_ASYMMETRIC_KEYS */
> +
>  int integrity_digsig_verify(const unsigned int id, const char *sig, int siglen,
>  					const char *digest, int digestlen)
>  {
> @@ -43,6 +140,10 @@ int integrity_digsig_verify(const unsigned int id, const char *sig, int siglen,
>  			return err;
>  		}
>  	}
> -
> +#ifdef CONFIG_INTEGRITY_ASYMMETRIC_KEYS
> +	if (sig[0] == 2)
> +		return asymmetric_verify(keyring[id], sig, siglen,
> +					 digest, digestlen);
> +#endif
>  	return digsig_verify(keyring[id], sig, siglen, digest, digestlen);
>  }

Thanks Dmitry for the patch!  According to
Documentation/SubmittingPatches: section 2.2, #ifdefs are ugly.  I
realize this is a really small '.c' file, and doesn't really hurt
readability, but could you remove the ifdefs anyway?

thanks,

Mimi

Re: [RFC 1/1] ima: digital signature verification using asymmetric keys

[Kasatkin, Dmitry]

On Wed, Jan 23, 2013 at 12:53 AM, Mimi Zohar <zohar@linux.vnet.ibm.com> wrote:
> On Tue, 2013-01-15 at 12:34 +0200, Dmitry Kasatkin wrote:
>> Asymmetric keys were introduced in linux-3.7 to verify the signature on
>> signed kernel modules.  The asymmetric keys infrastructure abstracts the
>> signature verification from the crypto details.  This patch adds IMA/EVM
>> signature verification using asymmetric keys.  Support for additional
>> signature verification methods can now be delegated to the asymmetric
>> key infrastructure.
>>
>> Signed-off-by: Dmitry Kasatkin <dmitry.kasatkin@intel.com>
>> ---
>>  security/integrity/Kconfig  |   12 +++++
>>  security/integrity/digsig.c |  103 ++++++++++++++++++++++++++++++++++++++++++-
>>  2 files changed, 114 insertions(+), 1 deletion(-)
>>
>> diff --git a/security/integrity/Kconfig b/security/integrity/Kconfig
>> index 5bd1cc1..19c4187 100644
>> --- a/security/integrity/Kconfig
>> +++ b/security/integrity/Kconfig
>> @@ -17,5 +17,17 @@ config INTEGRITY_SIGNATURE
>>         This is useful for evm and module keyrings, when keys are
>>         usually only added from initramfs.
>>
>> +config INTEGRITY_ASYMMETRIC_KEYS
>> +     boolean "Digital signature verification using asymmetric keys"
>> +     depends on INTEGRITY_SIGNATURE
>> +     default n
>> +        select ASYMMETRIC_KEY_TYPE
>> +        select ASYMMETRIC_PUBLIC_KEY_SUBTYPE
>> +        select PUBLIC_KEY_ALGO_RSA
>> +        select X509_CERTIFICATE_PARSER
>> +     help
>> +       This option enables digital signature verification support
>> +       using asymmetric keys.
>> +
>>  source security/integrity/ima/Kconfig
>>  source security/integrity/evm/Kconfig
>> diff --git a/security/integrity/digsig.c b/security/integrity/digsig.c
>> index 2dc167d..1896537 100644
>> --- a/security/integrity/digsig.c
>> +++ b/security/integrity/digsig.c
>> @@ -15,10 +15,22 @@
>>  #include <linux/err.h>
>>  #include <linux/rbtree.h>
>>  #include <linux/key-type.h>
>> +#include <crypto/public_key.h>
>> +#include <keys/asymmetric-type.h>
>>  #include <linux/digsig.h>
>>
>>  #include "integrity.h"
>>
>> +/*
>> + * signature format v2 - for using with asymmetric keys
>> + */
>> +struct signature_v2_hdr {
>> +     uint8_t version;        /* signature format version */
>> +     uint8_t hash_algo;      /* Digest algorithm [enum pkey_hash_algo] */
>> +     uint8_t keyid[8];       /* IMA key identifier - not X509/PGP specific*/
>> +     uint8_t payload[0];     /* signature payload */
>> +} __packed;
>> +
>>  static struct key *keyring[INTEGRITY_KEYRING_MAX];
>>
>>  static const char *keyring_name[INTEGRITY_KEYRING_MAX] = {
>> @@ -27,6 +39,91 @@ static const char *keyring_name[INTEGRITY_KEYRING_MAX] = {
>>       "_ima",
>>  };
>>
>> +#ifdef CONFIG_INTEGRITY_ASYMMETRIC_KEYS
>> +
>> +/*
>> + * Request an asymmetric key.
>> + */
>> +static struct key *request_asymmetric_key(struct key *keyring, uint8_t *keyid)
>> +{
>> +     struct key *key;
>> +     char name[20];
>> +
>> +     sprintf(name, "%llX", __be64_to_cpup((uint64_t *)keyid));
>> +
>> +     pr_debug("key search: \"%s\"\n", name);
>> +
>> +     if (keyring) {
>> +             /* search in specific keyring */
>> +             key_ref_t kref;
>> +             kref = keyring_search(make_key_ref(keyring, 1),
>> +                                   &key_type_asymmetric, name);
>> +             if (IS_ERR(kref))
>> +                     key = ERR_CAST(kref);
>> +             else
>> +                     key = key_ref_to_ptr(kref);
>> +     } else {
>> +             key = request_key(&key_type_asymmetric, name, NULL);
>> +     }
>> +
>> +     if (IS_ERR(key)) {
>> +             pr_warn("Request for unknown key '%s' err %ld\n",
>> +                     name, PTR_ERR(key));
>> +             switch (PTR_ERR(key)) {
>> +                     /* Hide some search errors */
>> +             case -EACCES:
>> +             case -ENOTDIR:
>> +             case -EAGAIN:
>> +                     return ERR_PTR(-ENOKEY);
>> +             default:
>> +                     return key;
>> +             }
>> +     }
>> +
>> +     pr_debug("%s() = 0 [%x]\n", __func__, key_serial(key));
>> +
>> +     return key;
>> +}
>> +
>> +static int asymmetric_verify(struct key *keyring, const char *sig,
>> +                          size_t siglen, const char *data, int datalen)
>> +{
>> +     struct public_key_signature pks;
>> +     struct signature_v2_hdr *hdr = (struct signature_v2_hdr *)sig;
>> +     struct key *key;
>> +     int ret = -ENOMEM;
>> +
>> +     if (siglen <= sizeof(*hdr))
>> +             return -EBADMSG;
>> +
>> +     siglen -= sizeof(*hdr);
>> +
>> +     if (hdr->hash_algo >= PKEY_HASH__LAST)
>> +             return -ENOPKG;
>> +
>> +     key = request_asymmetric_key(keyring, hdr->keyid);
>> +     if (IS_ERR(key))
>> +             return PTR_ERR(key);
>> +
>> +     memset(&pks, 0, sizeof(pks));
>> +
>> +     pks.pkey_hash_algo = hdr->hash_algo;
>> +     pks.digest = (u8 *)data;
>> +     pks.digest_size = datalen;
>> +     pks.nr_mpi = 1;
>> +     pks.rsa.s = mpi_read_from_buffer(hdr->payload, &siglen);
>> +
>> +     if (pks.rsa.s)
>> +             ret = verify_signature(key, &pks);
>> +
>> +     mpi_free(pks.rsa.s);
>> +     key_put(key);
>> +     pr_debug("%s() = %d\n", __func__, ret);
>> +     return ret;
>> +}
>> +
>> +#endif /* CONFIG_INTEGRITY_ASYMMETRIC_KEYS */
>> +
>>  int integrity_digsig_verify(const unsigned int id, const char *sig, int siglen,
>>                                       const char *digest, int digestlen)
>>  {
>> @@ -43,6 +140,10 @@ int integrity_digsig_verify(const unsigned int id, const char *sig, int siglen,
>>                       return err;
>>               }
>>       }
>> -
>> +#ifdef CONFIG_INTEGRITY_ASYMMETRIC_KEYS
>> +     if (sig[0] == 2)
>> +             return asymmetric_verify(keyring[id], sig, siglen,
>> +                                      digest, digestlen);
>> +#endif
>>       return digsig_verify(keyring[id], sig, siglen, digest, digestlen);
>>  }
>
> Thanks Dmitry for the patch!  According to
> Documentation/SubmittingPatches: section 2.2, #ifdefs are ugly.  I
> realize this is a really small '.c' file, and doesn't really hurt
> readability, but could you remove the ifdefs anyway?
>

Will do it.

- Dmitry

> thanks,
>
> Mimi
>
>
>
> --
> To unsubscribe from this list: send the line "unsubscribe linux-security-module" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [RFC 1/1] ima: digital signature verification using asymmetric keys

[Vivek Goyal]

Hi,

I am trying to read and understand IMA code. How does digital signature
mechanism work. 

IIUC, evmctl will install a file's signature in security.ima. And later
process_measurement() will do following.

Calculate digest of file in ima_collect_measurement() and then
ima_appraise_measurement() actually compares signatuer against the
digest.

If yes, ima_collect_measurement() always calculates digest either using
md5/sha1 but signatures might have used sha256 or something else. So
how does it work. What am I missing.

Thanks
Vivek

On Wed, Jan 23, 2013 at 11:03:39AM +0200, Kasatkin, Dmitry wrote:
> On Wed, Jan 23, 2013 at 12:53 AM, Mimi Zohar <zohar@linux.vnet.ibm.com> wrote:
> > On Tue, 2013-01-15 at 12:34 +0200, Dmitry Kasatkin wrote:
> >> Asymmetric keys were introduced in linux-3.7 to verify the signature on
> >> signed kernel modules.  The asymmetric keys infrastructure abstracts the
> >> signature verification from the crypto details.  This patch adds IMA/EVM
> >> signature verification using asymmetric keys.  Support for additional
> >> signature verification methods can now be delegated to the asymmetric
> >> key infrastructure.
> >>
> >> Signed-off-by: Dmitry Kasatkin <dmitry.kasatkin@intel.com>
> >> ---
> >>  security/integrity/Kconfig  |   12 +++++
> >>  security/integrity/digsig.c |  103 ++++++++++++++++++++++++++++++++++++++++++-
> >>  2 files changed, 114 insertions(+), 1 deletion(-)
> >>
> >> diff --git a/security/integrity/Kconfig b/security/integrity/Kconfig
> >> index 5bd1cc1..19c4187 100644
> >> --- a/security/integrity/Kconfig
> >> +++ b/security/integrity/Kconfig
> >> @@ -17,5 +17,17 @@ config INTEGRITY_SIGNATURE
> >>         This is useful for evm and module keyrings, when keys are
> >>         usually only added from initramfs.
> >>
> >> +config INTEGRITY_ASYMMETRIC_KEYS
> >> +     boolean "Digital signature verification using asymmetric keys"
> >> +     depends on INTEGRITY_SIGNATURE
> >> +     default n
> >> +        select ASYMMETRIC_KEY_TYPE
> >> +        select ASYMMETRIC_PUBLIC_KEY_SUBTYPE
> >> +        select PUBLIC_KEY_ALGO_RSA
> >> +        select X509_CERTIFICATE_PARSER
> >> +     help
> >> +       This option enables digital signature verification support
> >> +       using asymmetric keys.
> >> +
> >>  source security/integrity/ima/Kconfig
> >>  source security/integrity/evm/Kconfig
> >> diff --git a/security/integrity/digsig.c b/security/integrity/digsig.c
> >> index 2dc167d..1896537 100644
> >> --- a/security/integrity/digsig.c
> >> +++ b/security/integrity/digsig.c
> >> @@ -15,10 +15,22 @@
> >>  #include <linux/err.h>
> >>  #include <linux/rbtree.h>
> >>  #include <linux/key-type.h>
> >> +#include <crypto/public_key.h>
> >> +#include <keys/asymmetric-type.h>
> >>  #include <linux/digsig.h>
> >>
> >>  #include "integrity.h"
> >>
> >> +/*
> >> + * signature format v2 - for using with asymmetric keys
> >> + */
> >> +struct signature_v2_hdr {
> >> +     uint8_t version;        /* signature format version */
> >> +     uint8_t hash_algo;      /* Digest algorithm [enum pkey_hash_algo] */
> >> +     uint8_t keyid[8];       /* IMA key identifier - not X509/PGP specific*/
> >> +     uint8_t payload[0];     /* signature payload */
> >> +} __packed;
> >> +
> >>  static struct key *keyring[INTEGRITY_KEYRING_MAX];
> >>
> >>  static const char *keyring_name[INTEGRITY_KEYRING_MAX] = {
> >> @@ -27,6 +39,91 @@ static const char *keyring_name[INTEGRITY_KEYRING_MAX] = {
> >>       "_ima",
> >>  };
> >>
> >> +#ifdef CONFIG_INTEGRITY_ASYMMETRIC_KEYS
> >> +
> >> +/*
> >> + * Request an asymmetric key.
> >> + */
> >> +static struct key *request_asymmetric_key(struct key *keyring, uint8_t *keyid)
> >> +{
> >> +     struct key *key;
> >> +     char name[20];
> >> +
> >> +     sprintf(name, "%llX", __be64_to_cpup((uint64_t *)keyid));
> >> +
> >> +     pr_debug("key search: \"%s\"\n", name);
> >> +
> >> +     if (keyring) {
> >> +             /* search in specific keyring */
> >> +             key_ref_t kref;
> >> +             kref = keyring_search(make_key_ref(keyring, 1),
> >> +                                   &key_type_asymmetric, name);
> >> +             if (IS_ERR(kref))
> >> +                     key = ERR_CAST(kref);
> >> +             else
> >> +                     key = key_ref_to_ptr(kref);
> >> +     } else {
> >> +             key = request_key(&key_type_asymmetric, name, NULL);
> >> +     }
> >> +
> >> +     if (IS_ERR(key)) {
> >> +             pr_warn("Request for unknown key '%s' err %ld\n",
> >> +                     name, PTR_ERR(key));
> >> +             switch (PTR_ERR(key)) {
> >> +                     /* Hide some search errors */
> >> +             case -EACCES:
> >> +             case -ENOTDIR:
> >> +             case -EAGAIN:
> >> +                     return ERR_PTR(-ENOKEY);
> >> +             default:
> >> +                     return key;
> >> +             }
> >> +     }
> >> +
> >> +     pr_debug("%s() = 0 [%x]\n", __func__, key_serial(key));
> >> +
> >> +     return key;
> >> +}
> >> +
> >> +static int asymmetric_verify(struct key *keyring, const char *sig,
> >> +                          size_t siglen, const char *data, int datalen)
> >> +{
> >> +     struct public_key_signature pks;
> >> +     struct signature_v2_hdr *hdr = (struct signature_v2_hdr *)sig;
> >> +     struct key *key;
> >> +     int ret = -ENOMEM;
> >> +
> >> +     if (siglen <= sizeof(*hdr))
> >> +             return -EBADMSG;
> >> +
> >> +     siglen -= sizeof(*hdr);
> >> +
> >> +     if (hdr->hash_algo >= PKEY_HASH__LAST)
> >> +             return -ENOPKG;
> >> +
> >> +     key = request_asymmetric_key(keyring, hdr->keyid);
> >> +     if (IS_ERR(key))
> >> +             return PTR_ERR(key);
> >> +
> >> +     memset(&pks, 0, sizeof(pks));
> >> +
> >> +     pks.pkey_hash_algo = hdr->hash_algo;
> >> +     pks.digest = (u8 *)data;
> >> +     pks.digest_size = datalen;
> >> +     pks.nr_mpi = 1;
> >> +     pks.rsa.s = mpi_read_from_buffer(hdr->payload, &siglen);
> >> +
> >> +     if (pks.rsa.s)
> >> +             ret = verify_signature(key, &pks);
> >> +
> >> +     mpi_free(pks.rsa.s);
> >> +     key_put(key);
> >> +     pr_debug("%s() = %d\n", __func__, ret);
> >> +     return ret;
> >> +}
> >> +
> >> +#endif /* CONFIG_INTEGRITY_ASYMMETRIC_KEYS */
> >> +
> >>  int integrity_digsig_verify(const unsigned int id, const char *sig, int siglen,
> >>                                       const char *digest, int digestlen)
> >>  {
> >> @@ -43,6 +140,10 @@ int integrity_digsig_verify(const unsigned int id, const char *sig, int siglen,
> >>                       return err;
> >>               }
> >>       }
> >> -
> >> +#ifdef CONFIG_INTEGRITY_ASYMMETRIC_KEYS
> >> +     if (sig[0] == 2)
> >> +             return asymmetric_verify(keyring[id], sig, siglen,
> >> +                                      digest, digestlen);
> >> +#endif
> >>       return digsig_verify(keyring[id], sig, siglen, digest, digestlen);
> >>  }
> >
> > Thanks Dmitry for the patch!  According to
> > Documentation/SubmittingPatches: section 2.2, #ifdefs are ugly.  I
> > realize this is a really small '.c' file, and doesn't really hurt
> > readability, but could you remove the ifdefs anyway?
> >
> 
> Will do it.
> 
> - Dmitry
> 
> > thanks,
> >
> > Mimi
> >
> >
> >
> > --
> > To unsubscribe from this list: send the line "unsubscribe linux-security-module" in
> > the body of a message to majordomo@vger.kernel.org
> > More majordomo info at  http://vger.kernel.org/majordomo-info.html
> --
> To unsubscribe from this list: send the line "unsubscribe linux-security-module" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [RFC 1/1] ima: digital signature verification using asymmetric keys

[Kasatkin, Dmitry]

On Fri, Jan 25, 2013 at 11:01 PM, Vivek Goyal <vgoyal@redhat.com> wrote:
> Hi,
>
> I am trying to read and understand IMA code. How does digital signature
> mechanism work.
>
> IIUC, evmctl will install a file's signature in security.ima. And later
> process_measurement() will do following.
>
> Calculate digest of file in ima_collect_measurement() and then
> ima_appraise_measurement() actually compares signatuer against the
> digest.
>
> If yes, ima_collect_measurement() always calculates digest either using
> md5/sha1 but signatures might have used sha256 or something else. So
> how does it work. What am I missing.

Hi,

Yes, currently it is possible to use only single configured algorithm, which is
in generally enough. Consider it like a policy.
Soon it will be a patch which allows to use any hash algorithms, supported by
asymmetric key verification API.

- Dmitry


>
> Thanks
> Vivek
>
> On Wed, Jan 23, 2013 at 11:03:39AM +0200, Kasatkin, Dmitry wrote:
>> On Wed, Jan 23, 2013 at 12:53 AM, Mimi Zohar <zohar@linux.vnet.ibm.com> wrote:
>> > On Tue, 2013-01-15 at 12:34 +0200, Dmitry Kasatkin wrote:
>> >> Asymmetric keys were introduced in linux-3.7 to verify the signature on
>> >> signed kernel modules.  The asymmetric keys infrastructure abstracts the
>> >> signature verification from the crypto details.  This patch adds IMA/EVM
>> >> signature verification using asymmetric keys.  Support for additional
>> >> signature verification methods can now be delegated to the asymmetric
>> >> key infrastructure.
>> >>
>> >> Signed-off-by: Dmitry Kasatkin <dmitry.kasatkin@intel.com>
>> >> ---
>> >>  security/integrity/Kconfig  |   12 +++++
>> >>  security/integrity/digsig.c |  103 ++++++++++++++++++++++++++++++++++++++++++-
>> >>  2 files changed, 114 insertions(+), 1 deletion(-)
>> >>
>> >> diff --git a/security/integrity/Kconfig b/security/integrity/Kconfig
>> >> index 5bd1cc1..19c4187 100644
>> >> --- a/security/integrity/Kconfig
>> >> +++ b/security/integrity/Kconfig
>> >> @@ -17,5 +17,17 @@ config INTEGRITY_SIGNATURE
>> >>         This is useful for evm and module keyrings, when keys are
>> >>         usually only added from initramfs.
>> >>
>> >> +config INTEGRITY_ASYMMETRIC_KEYS
>> >> +     boolean "Digital signature verification using asymmetric keys"
>> >> +     depends on INTEGRITY_SIGNATURE
>> >> +     default n
>> >> +        select ASYMMETRIC_KEY_TYPE
>> >> +        select ASYMMETRIC_PUBLIC_KEY_SUBTYPE
>> >> +        select PUBLIC_KEY_ALGO_RSA
>> >> +        select X509_CERTIFICATE_PARSER
>> >> +     help
>> >> +       This option enables digital signature verification support
>> >> +       using asymmetric keys.
>> >> +
>> >>  source security/integrity/ima/Kconfig
>> >>  source security/integrity/evm/Kconfig
>> >> diff --git a/security/integrity/digsig.c b/security/integrity/digsig.c
>> >> index 2dc167d..1896537 100644
>> >> --- a/security/integrity/digsig.c
>> >> +++ b/security/integrity/digsig.c
>> >> @@ -15,10 +15,22 @@
>> >>  #include <linux/err.h>
>> >>  #include <linux/rbtree.h>
>> >>  #include <linux/key-type.h>
>> >> +#include <crypto/public_key.h>
>> >> +#include <keys/asymmetric-type.h>
>> >>  #include <linux/digsig.h>
>> >>
>> >>  #include "integrity.h"
>> >>
>> >> +/*
>> >> + * signature format v2 - for using with asymmetric keys
>> >> + */
>> >> +struct signature_v2_hdr {
>> >> +     uint8_t version;        /* signature format version */
>> >> +     uint8_t hash_algo;      /* Digest algorithm [enum pkey_hash_algo] */
>> >> +     uint8_t keyid[8];       /* IMA key identifier - not X509/PGP specific*/
>> >> +     uint8_t payload[0];     /* signature payload */
>> >> +} __packed;
>> >> +
>> >>  static struct key *keyring[INTEGRITY_KEYRING_MAX];
>> >>
>> >>  static const char *keyring_name[INTEGRITY_KEYRING_MAX] = {
>> >> @@ -27,6 +39,91 @@ static const char *keyring_name[INTEGRITY_KEYRING_MAX] = {
>> >>       "_ima",
>> >>  };
>> >>
>> >> +#ifdef CONFIG_INTEGRITY_ASYMMETRIC_KEYS
>> >> +
>> >> +/*
>> >> + * Request an asymmetric key.
>> >> + */
>> >> +static struct key *request_asymmetric_key(struct key *keyring, uint8_t *keyid)
>> >> +{
>> >> +     struct key *key;
>> >> +     char name[20];
>> >> +
>> >> +     sprintf(name, "%llX", __be64_to_cpup((uint64_t *)keyid));
>> >> +
>> >> +     pr_debug("key search: \"%s\"\n", name);
>> >> +
>> >> +     if (keyring) {
>> >> +             /* search in specific keyring */
>> >> +             key_ref_t kref;
>> >> +             kref = keyring_search(make_key_ref(keyring, 1),
>> >> +                                   &key_type_asymmetric, name);
>> >> +             if (IS_ERR(kref))
>> >> +                     key = ERR_CAST(kref);
>> >> +             else
>> >> +                     key = key_ref_to_ptr(kref);
>> >> +     } else {
>> >> +             key = request_key(&key_type_asymmetric, name, NULL);
>> >> +     }
>> >> +
>> >> +     if (IS_ERR(key)) {
>> >> +             pr_warn("Request for unknown key '%s' err %ld\n",
>> >> +                     name, PTR_ERR(key));
>> >> +             switch (PTR_ERR(key)) {
>> >> +                     /* Hide some search errors */
>> >> +             case -EACCES:
>> >> +             case -ENOTDIR:
>> >> +             case -EAGAIN:
>> >> +                     return ERR_PTR(-ENOKEY);
>> >> +             default:
>> >> +                     return key;
>> >> +             }
>> >> +     }
>> >> +
>> >> +     pr_debug("%s() = 0 [%x]\n", __func__, key_serial(key));
>> >> +
>> >> +     return key;
>> >> +}
>> >> +
>> >> +static int asymmetric_verify(struct key *keyring, const char *sig,
>> >> +                          size_t siglen, const char *data, int datalen)
>> >> +{
>> >> +     struct public_key_signature pks;
>> >> +     struct signature_v2_hdr *hdr = (struct signature_v2_hdr *)sig;
>> >> +     struct key *key;
>> >> +     int ret = -ENOMEM;
>> >> +
>> >> +     if (siglen <= sizeof(*hdr))
>> >> +             return -EBADMSG;
>> >> +
>> >> +     siglen -= sizeof(*hdr);
>> >> +
>> >> +     if (hdr->hash_algo >= PKEY_HASH__LAST)
>> >> +             return -ENOPKG;
>> >> +
>> >> +     key = request_asymmetric_key(keyring, hdr->keyid);
>> >> +     if (IS_ERR(key))
>> >> +             return PTR_ERR(key);
>> >> +
>> >> +     memset(&pks, 0, sizeof(pks));
>> >> +
>> >> +     pks.pkey_hash_algo = hdr->hash_algo;
>> >> +     pks.digest = (u8 *)data;
>> >> +     pks.digest_size = datalen;
>> >> +     pks.nr_mpi = 1;
>> >> +     pks.rsa.s = mpi_read_from_buffer(hdr->payload, &siglen);
>> >> +
>> >> +     if (pks.rsa.s)
>> >> +             ret = verify_signature(key, &pks);
>> >> +
>> >> +     mpi_free(pks.rsa.s);
>> >> +     key_put(key);
>> >> +     pr_debug("%s() = %d\n", __func__, ret);
>> >> +     return ret;
>> >> +}
>> >> +
>> >> +#endif /* CONFIG_INTEGRITY_ASYMMETRIC_KEYS */
>> >> +
>> >>  int integrity_digsig_verify(const unsigned int id, const char *sig, int siglen,
>> >>                                       const char *digest, int digestlen)
>> >>  {
>> >> @@ -43,6 +140,10 @@ int integrity_digsig_verify(const unsigned int id, const char *sig, int siglen,
>> >>                       return err;
>> >>               }
>> >>       }
>> >> -
>> >> +#ifdef CONFIG_INTEGRITY_ASYMMETRIC_KEYS
>> >> +     if (sig[0] == 2)
>> >> +             return asymmetric_verify(keyring[id], sig, siglen,
>> >> +                                      digest, digestlen);
>> >> +#endif
>> >>       return digsig_verify(keyring[id], sig, siglen, digest, digestlen);
>> >>  }
>> >
>> > Thanks Dmitry for the patch!  According to
>> > Documentation/SubmittingPatches: section 2.2, #ifdefs are ugly.  I
>> > realize this is a really small '.c' file, and doesn't really hurt
>> > readability, but could you remove the ifdefs anyway?
>> >
>>
>> Will do it.
>>
>> - Dmitry
>>
>> > thanks,
>> >
>> > Mimi
>> >
>> >
>> >
>> > --
>> > To unsubscribe from this list: send the line "unsubscribe linux-security-module" in
>> > the body of a message to majordomo@vger.kernel.org
>> > More majordomo info at  http://vger.kernel.org/majordomo-info.html
>> --
>> To unsubscribe from this list: send the line "unsubscribe linux-security-module" in
>> the body of a message to majordomo@vger.kernel.org
>> More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [RFC 1/1] ima: digital signature verification using asymmetric keys

[Vivek Goyal]

On Mon, Jan 28, 2013 at 04:54:06PM +0200, Kasatkin, Dmitry wrote:
> On Fri, Jan 25, 2013 at 11:01 PM, Vivek Goyal <vgoyal@redhat.com> wrote:
> > Hi,
> >
> > I am trying to read and understand IMA code. How does digital signature
> > mechanism work.
> >
> > IIUC, evmctl will install a file's signature in security.ima. And later
> > process_measurement() will do following.
> >
> > Calculate digest of file in ima_collect_measurement() and then
> > ima_appraise_measurement() actually compares signatuer against the
> > digest.
> >
> > If yes, ima_collect_measurement() always calculates digest either using
> > md5/sha1 but signatures might have used sha256 or something else. So
> > how does it work. What am I missing.
> 
> Hi,
> 
> Yes, currently it is possible to use only single configured algorithm, which is
> in generally enough. Consider it like a policy.
> Soon it will be a patch which allows to use any hash algorithms, supported by
> asymmetric key verification API.

Ok. I am hoping that it will be more than the kernel command line we
support. In the sense that for digital signatures one needs to parse
the signature, look at what hash algorithm has been used  and then
collect the hash accordingly. It is little different then IMA requirement
of calculating one pre-determine hash for all files.

Thanks
Vivek

Re: [RFC 1/1] ima: digital signature verification using asymmetric keys

[Kasatkin, Dmitry]

On Mon, Jan 28, 2013 at 5:15 PM, Vivek Goyal <vgoyal@redhat.com> wrote:
> On Mon, Jan 28, 2013 at 04:54:06PM +0200, Kasatkin, Dmitry wrote:
>> On Fri, Jan 25, 2013 at 11:01 PM, Vivek Goyal <vgoyal@redhat.com> wrote:
>> > Hi,
>> >
>> > I am trying to read and understand IMA code. How does digital signature
>> > mechanism work.
>> >
>> > IIUC, evmctl will install a file's signature in security.ima. And later
>> > process_measurement() will do following.
>> >
>> > Calculate digest of file in ima_collect_measurement() and then
>> > ima_appraise_measurement() actually compares signatuer against the
>> > digest.
>> >
>> > If yes, ima_collect_measurement() always calculates digest either using
>> > md5/sha1 but signatures might have used sha256 or something else. So
>> > how does it work. What am I missing.
>>
>> Hi,
>>
>> Yes, currently it is possible to use only single configured algorithm, which is
>> in generally enough. Consider it like a policy.
>> Soon it will be a patch which allows to use any hash algorithms, supported by
>> asymmetric key verification API.
>
> Ok. I am hoping that it will be more than the kernel command line we
> support. In the sense that for digital signatures one needs to parse
> the signature, look at what hash algorithm has been used  and then
> collect the hash accordingly. It is little different then IMA requirement
> of calculating one pre-determine hash for all files.

Yes... It is obvious. It's coming.
But in general, signer should be aware of requirements and limitation
of the platform.
It is not really a problem...

- Dmitry

>
> Thanks
> Vivek

Re: [RFC 1/1] ima: digital signature verification using asymmetric keys

[Vivek Goyal]

On Mon, Jan 28, 2013 at 05:20:20PM +0200, Kasatkin, Dmitry wrote:

[..]
> > Ok. I am hoping that it will be more than the kernel command line we
> > support. In the sense that for digital signatures one needs to parse
> > the signature, look at what hash algorithm has been used  and then
> > collect the hash accordingly. It is little different then IMA requirement
> > of calculating one pre-determine hash for all files.
> 
> Yes... It is obvious. It's coming.
> But in general, signer should be aware of requirements and limitation
> of the platform.
> It is not really a problem...

Ok, I have another question. I was looking at your slide deck here.

http://selinuxproject.org/~jmorris/lss2011_slides/IMA_EVM_Digital_Signature_Support.pdf

Slide 12 mentions that keys are loaded into the kernel from initramfs. If
"root" can load any key, what are we protecting against.

IOW, what good ima_appraise_tcb policy, which tries to appraise any root
owned file.  A root can sign all the files using its own key and load its
public key in IMA keyring and then integrity check should pass on all
root files.

So what's the idea behind digital signature appraisal? By allowing root to
unconditionally load the keys in IMA keyring, it seems to circumvent the
appraisal mechanism.

Thanks
Vivek

Re: [RFC 1/1] ima: digital signature verification using asymmetric keys

[Mimi Zohar]

On Mon, 2013-01-28 at 13:52 -0500, Vivek Goyal wrote:
> On Mon, Jan 28, 2013 at 05:20:20PM +0200, Kasatkin, Dmitry wrote:
> 
> [..]
> > > Ok. I am hoping that it will be more than the kernel command line we
> > > support. In the sense that for digital signatures one needs to parse
> > > the signature, look at what hash algorithm has been used  and then
> > > collect the hash accordingly. It is little different then IMA requirement
> > > of calculating one pre-determine hash for all files.
> > 
> > Yes... It is obvious. It's coming.
> > But in general, signer should be aware of requirements and limitation
> > of the platform.
> > It is not really a problem...
> 
> Ok, I have another question. I was looking at your slide deck here.
> 
> http://selinuxproject.org/~jmorris/lss2011_slides/IMA_EVM_Digital_Signature_Support.pdf
> 
> Slide 12 mentions that keys are loaded into the kernel from initramfs. If
> "root" can load any key, what are we protecting against.
> 
> IOW, what good ima_appraise_tcb policy, which tries to appraise any root
> owned file.  A root can sign all the files using its own key and load its
> public key in IMA keyring and then integrity check should pass on all
> root files.

> So what's the idea behind digital signature appraisal? By allowing root to
> unconditionally load the keys in IMA keyring, it seems to circumvent the
> appraisal mechanism.

Vivek, you're asking obvious questions, without understanding that what
you want to do is only now possible because of the work that has gone
into upstreaming the different components of the linux-integrity
subsystem (eg. IMA, trusted/encrypted keys, EVM, (MPI library), and now
IMA-appraisal).  In case you weren't aware, Dmitry made the necessary
changes so that the MPI library could be upstreamed for
EVM/IMA-appraisal digital signature support.

I'm pretty sure that keyrings can be locked, preventing additional keys
from being added.  (If it isn't currently supported, it needs to be.)
The _evm and _ima keyrings should definitely be locked.  When/how this
is done, is yet to be defined.  I'm pretty sure there are a number of
people thinking about this, including David Howells, Dmitry Kataskin,
David Safford and myself.

As I previously said, the next steps are to integrate the
EVM/IMA-appraisal public keys in a safe and trusted manner, without
breaking the secure boot signature chain.

thanks,

Mimi

Re: [RFC 1/1] ima: digital signature verification using asymmetric keys

[Vivek Goyal]

On Mon, Jan 28, 2013 at 02:51:34PM -0500, Mimi Zohar wrote:
> On Mon, 2013-01-28 at 13:52 -0500, Vivek Goyal wrote:
> > On Mon, Jan 28, 2013 at 05:20:20PM +0200, Kasatkin, Dmitry wrote:
> > 
> > [..]
> > > > Ok. I am hoping that it will be more than the kernel command line we
> > > > support. In the sense that for digital signatures one needs to parse
> > > > the signature, look at what hash algorithm has been used  and then
> > > > collect the hash accordingly. It is little different then IMA requirement
> > > > of calculating one pre-determine hash for all files.
> > > 
> > > Yes... It is obvious. It's coming.
> > > But in general, signer should be aware of requirements and limitation
> > > of the platform.
> > > It is not really a problem...
> > 
> > Ok, I have another question. I was looking at your slide deck here.
> > 
> > http://selinuxproject.org/~jmorris/lss2011_slides/IMA_EVM_Digital_Signature_Support.pdf
> > 
> > Slide 12 mentions that keys are loaded into the kernel from initramfs. If
> > "root" can load any key, what are we protecting against.
> > 
> > IOW, what good ima_appraise_tcb policy, which tries to appraise any root
> > owned file.  A root can sign all the files using its own key and load its
> > public key in IMA keyring and then integrity check should pass on all
> > root files.
> 
> > So what's the idea behind digital signature appraisal? By allowing root to
> > unconditionally load the keys in IMA keyring, it seems to circumvent the
> > appraisal mechanism.
> 
> Vivek, you're asking obvious questions, without understanding that what
> you want to do is only now possible because of the work that has gone
> into upstreaming the different components of the linux-integrity
> subsystem (eg. IMA, trusted/encrypted keys, EVM, (MPI library), and now
> IMA-appraisal).  In case you weren't aware, Dmitry made the necessary
> changes so that the MPI library could be upstreamed for
> EVM/IMA-appraisal digital signature support.

Hi Mimi,

Sure. I am just trying to understand that where are we and how can I 
help improve things so that I can achieve my objectives.

The problem I am running into is that I can't find a single good 
documentation here which explains how to use things. There is no
single .txt file in Documentation/ directory which explains current
state of affiars or which explains how to use any of the IMA/EVM
functionality. 

So I have no way left but to read code and ask obivious questions
on mailing list to figure out what components are working, what
components are work in progress or what's the intent of components
and how they are supposed to be used.

So are we saying that all the appraisal and digital signature stuff
is not useful till we figure a way out to lock down IMA keyring. Or
it is useful only when root can load the keyring but we are trying
to appraise only non-root files.

> 
> I'm pretty sure that keyrings can be locked, preventing additional keys
> from being added.  (If it isn't currently supported, it needs to be.)
> The _evm and _ima keyrings should definitely be locked.  When/how this
> is done, is yet to be defined.  I'm pretty sure there are a number of
> people thinking about this, including David Howells, Dmitry Kataskin,
> David Safford and myself.
> 
> As I previously said, the next steps are to integrate the
> EVM/IMA-appraisal public keys in a safe and trusted manner, without
> breaking the secure boot signature chain.

In a private conversation David howells mentioned that IMA keyring
should allow loading only if new key is trusted by an already loaded
key. He has already posted some patches for marking a keyring trusted
and loading keys only if it is signed by a trusted key.

We were wondring that what use case is served by allowing the root
to load keys unconditionally. By understanding the use case, atleast
one can try not to break it.

Thanks
Vivek

Re: [RFC 1/1] ima: digital signature verification using asymmetric keys

[Mimi Zohar]

On Mon, 2013-01-28 at 15:13 -0500, Vivek Goyal wrote:
> On Mon, Jan 28, 2013 at 02:51:34PM -0500, Mimi Zohar wrote:
> > On Mon, 2013-01-28 at 13:52 -0500, Vivek Goyal wrote:
> > > On Mon, Jan 28, 2013 at 05:20:20PM +0200, Kasatkin, Dmitry wrote:
> > > 
> > > [..]
> > > > > Ok. I am hoping that it will be more than the kernel command line we
> > > > > support. In the sense that for digital signatures one needs to parse
> > > > > the signature, look at what hash algorithm has been used  and then
> > > > > collect the hash accordingly. It is little different then IMA requirement
> > > > > of calculating one pre-determine hash for all files.
> > > > 
> > > > Yes... It is obvious. It's coming.
> > > > But in general, signer should be aware of requirements and limitation
> > > > of the platform.
> > > > It is not really a problem...
> > > 
> > > Ok, I have another question. I was looking at your slide deck here.
> > > 
> > > http://selinuxproject.org/~jmorris/lss2011_slides/IMA_EVM_Digital_Signature_Support.pdf
> > > 
> > > Slide 12 mentions that keys are loaded into the kernel from initramfs. If
> > > "root" can load any key, what are we protecting against.
> > > 
> > > IOW, what good ima_appraise_tcb policy, which tries to appraise any root
> > > owned file.  A root can sign all the files using its own key and load its
> > > public key in IMA keyring and then integrity check should pass on all
> > > root files.
> > 
> > > So what's the idea behind digital signature appraisal? By allowing root to
> > > unconditionally load the keys in IMA keyring, it seems to circumvent the
> > > appraisal mechanism.
> > 
> > Vivek, you're asking obvious questions, without understanding that what
> > you want to do is only now possible because of the work that has gone
> > into upstreaming the different components of the linux-integrity
> > subsystem (eg. IMA, trusted/encrypted keys, EVM, (MPI library), and now
> > IMA-appraisal).  In case you weren't aware, Dmitry made the necessary
> > changes so that the MPI library could be upstreamed for
> > EVM/IMA-appraisal digital signature support.
> 
> Hi Mimi,
> 
> Sure. I am just trying to understand that where are we and how can I 
> help improve things so that I can achieve my objectives.

The slides from the LSS 2012 linux-integrity subsystem status update,
are a bit dated, but at least shows where we're headed.

> The problem I am running into is that I can't find a single good 
> documentation here which explains how to use things. There is no
> single .txt file in Documentation/ directory which explains current
> state of affiars or which explains how to use any of the IMA/EVM
> functionality. 

Sorry, I've been lax in updating the linux-ima sourceforge website.
Usage questions should be posted on the linux-ima-user mailing list.

> So I have no way left but to read code and ask obivious questions
> on mailing list to figure out what components are working, what
> components are work in progress or what's the intent of components
> and how they are supposed to be used.

> So are we saying that all the appraisal and digital signature stuff
> is not useful till we figure a way out to lock down IMA keyring. Or
> it is useful only when root can load the keyring but we are trying
> to appraise only non-root files.

The IMA-appraisal hash was originally protected by EVM and the hmac key,
which was loaded once at boot time, from a TPM based trusted key or
initrd entered passphrase.  With IMA-appraisal digital signature
support, a new keyring for the IMA public keys was added, but without
the needed protection.  David Howell's new 'trusted' keyring would be an
excellent solution to control adding public keys.  (Using the term
'trusted' for both a key type and asymmetric keyring is confusing.)

> > I'm pretty sure that keyrings can be locked, preventing additional keys
> > from being added.  (If it isn't currently supported, it needs to be.)
> > The _evm and _ima keyrings should definitely be locked.  When/how this
> > is done, is yet to be defined.  I'm pretty sure there are a number of
> > people thinking about this, including David Howells, Dmitry Kataskin,
> > David Safford and myself.
> > 
> > As I previously said, the next steps are to integrate the
> > EVM/IMA-appraisal public keys in a safe and trusted manner, without
> > breaking the secure boot signature chain.
> 
> In a private conversation David howells mentioned that IMA keyring
> should allow loading only if new key is trusted by an already loaded
> key. He has already posted some patches for marking a keyring trusted
> and loading keys only if it is signed by a trusted key.

Please feel free to post patches for IMA-appraisal to use the new
'trusted' keyring.

> We were wondring that what use case is served by allowing the root
> to load keys unconditionally. By understanding the use case, atleast
> one can try not to break it.

At some point, there was a discussion on adding a new integrity
capability, with making the package installer a guard process.  With the
new 'trusted' keyring type, this probably isn't necessary.  

The 'trusted' keyring is a solution for installing only distro or third
party signed packages.  How would a developer, for instance, create,
sign, and install his own package and add his public key safely?

thanks,

Mimi

Re: [RFC 1/1] ima: digital signature verification using asymmetric keys

[Vivek Goyal]

On Mon, Jan 28, 2013 at 07:14:02PM -0500, Mimi Zohar wrote:

[..]
> The 'trusted' keyring is a solution for installing only distro or third
> party signed packages.  How would a developer, for instance, create,
> sign, and install his own package and add his public key safely?

Hi Mimi,

I guess using MOK, developer should be able to import his public key in
shim database and in turn in kernel and use that to load user signed
moduels.

Thanks
Vivek

Re: [RFC 1/1] ima: digital signature verification using asymmetric keys

[Kasatkin, Dmitry]

On Mon, Jan 28, 2013 at 10:13 PM, Vivek Goyal <vgoyal@redhat.com> wrote:
> On Mon, Jan 28, 2013 at 02:51:34PM -0500, Mimi Zohar wrote:
>> On Mon, 2013-01-28 at 13:52 -0500, Vivek Goyal wrote:
>> > On Mon, Jan 28, 2013 at 05:20:20PM +0200, Kasatkin, Dmitry wrote:
>> >
>> > [..]
>> > > > Ok. I am hoping that it will be more than the kernel command line we
>> > > > support. In the sense that for digital signatures one needs to parse
>> > > > the signature, look at what hash algorithm has been used  and then
>> > > > collect the hash accordingly. It is little different then IMA requirement
>> > > > of calculating one pre-determine hash for all files.
>> > >
>> > > Yes... It is obvious. It's coming.
>> > > But in general, signer should be aware of requirements and limitation
>> > > of the platform.
>> > > It is not really a problem...
>> >
>> > Ok, I have another question. I was looking at your slide deck here.
>> >
>> > http://selinuxproject.org/~jmorris/lss2011_slides/IMA_EVM_Digital_Signature_Support.pdf
>> >
>> > Slide 12 mentions that keys are loaded into the kernel from initramfs. If
>> > "root" can load any key, what are we protecting against.
>> >
>> > IOW, what good ima_appraise_tcb policy, which tries to appraise any root
>> > owned file.  A root can sign all the files using its own key and load its
>> > public key in IMA keyring and then integrity check should pass on all
>> > root files.
>>
>> > So what's the idea behind digital signature appraisal? By allowing root to
>> > unconditionally load the keys in IMA keyring, it seems to circumvent the
>> > appraisal mechanism.
>>
>> Vivek, you're asking obvious questions, without understanding that what
>> you want to do is only now possible because of the work that has gone
>> into upstreaming the different components of the linux-integrity
>> subsystem (eg. IMA, trusted/encrypted keys, EVM, (MPI library), and now
>> IMA-appraisal).  In case you weren't aware, Dmitry made the necessary
>> changes so that the MPI library could be upstreamed for
>> EVM/IMA-appraisal digital signature support.
>
> Hi Mimi,
>
> Sure. I am just trying to understand that where are we and how can I
> help improve things so that I can achieve my objectives.
>
> The problem I am running into is that I can't find a single good
> documentation here which explains how to use things. There is no
> single .txt file in Documentation/ directory which explains current
> state of affiars or which explains how to use any of the IMA/EVM
> functionality.
>

There is Wiki page available which contains lots of examples and explanations.

http://sourceforge.net/p/linux-ima/wiki/Home/

This is an Open Source project. Anyone can contribute and improve it.
If you find that something is unclear or missing in the wiki, you are
welcome to contribute/


> So I have no way left but to read code and ask obivious questions
> on mailing list to figure out what components are working, what
> components are work in progress or what's the intent of components
> and how they are supposed to be used.
>
> So are we saying that all the appraisal and digital signature stuff
> is not useful till we figure a way out to lock down IMA keyring. Or
> it is useful only when root can load the keyring but we are trying
> to appraise only non-root files.
>
>>
>> I'm pretty sure that keyrings can be locked, preventing additional keys
>> from being added.  (If it isn't currently supported, it needs to be.)
>> The _evm and _ima keyrings should definitely be locked.  When/how this
>> is done, is yet to be defined.  I'm pretty sure there are a number of
>> people thinking about this, including David Howells, Dmitry Kataskin,
>> David Safford and myself.
>>
>> As I previously said, the next steps are to integrate the
>> EVM/IMA-appraisal public keys in a safe and trusted manner, without
>> breaking the secure boot signature chain.
>
> In a private conversation David howells mentioned that IMA keyring
> should allow loading only if new key is trusted by an already loaded
> key. He has already posted some patches for marking a keyring trusted
> and loading keys only if it is signed by a trusted key.
>
> We were wondring that what use case is served by allowing the root
> to load keys unconditionally. By understanding the use case, atleast
> one can try not to break it.

Please read my previous email on how to lock down the kernel keyring.

- Dmitry

>
> Thanks
> Vivek

Re: [RFC 1/1] ima: digital signature verification using asymmetric keys

[Kasatkin, Dmitry]

On Mon, Jan 28, 2013 at 8:52 PM, Vivek Goyal <vgoyal@redhat.com> wrote:
> On Mon, Jan 28, 2013 at 05:20:20PM +0200, Kasatkin, Dmitry wrote:
>
> [..]
>> > Ok. I am hoping that it will be more than the kernel command line we
>> > support. In the sense that for digital signatures one needs to parse
>> > the signature, look at what hash algorithm has been used  and then
>> > collect the hash accordingly. It is little different then IMA requirement
>> > of calculating one pre-determine hash for all files.
>>
>> Yes... It is obvious. It's coming.
>> But in general, signer should be aware of requirements and limitation
>> of the platform.
>> It is not really a problem...
>
> Ok, I have another question. I was looking at your slide deck here.
>
> http://selinuxproject.org/~jmorris/lss2011_slides/IMA_EVM_Digital_Signature_Support.pdf
>
> Slide 12 mentions that keys are loaded into the kernel from initramfs. If
> "root" can load any key, what are we protecting against.
>
> IOW, what good ima_appraise_tcb policy, which tries to appraise any root
> owned file.  A root can sign all the files using its own key and load its
> public key in IMA keyring and then integrity check should pass on all
> root files.
>
> So what's the idea behind digital signature appraisal? By allowing root to
> unconditionally load the keys in IMA keyring, it seems to circumvent the
> appraisal mechanism.
>

I will answer directly to this email first.
'keyctl setperm' command is used to lock keyring from being able to
add new keys...
Even root is not able to revert locked keyring to original
write-permissive mode.

root@ubuntu:~# cat /proc/keys |grep ima
16a4c685 I--Q---     1 perm 3f010000     0     0 keyring   _ima: 2/4
root@ubuntu:~# keyctl setperm 379897477  0x0b010000
root@ubuntu:~# keyctl add user testkey "testing1" 379897477
add_key: Permission denied
root@ubuntu:~# keyctl setperm 379897477  0x3f010000
keyctl_setperm: Permission denied
root@ubuntu:~# cat /proc/keys |grep ima
16a4c685 I--Q---     1 perm 0b010000     0     0 keyring   _ima: 3/4


- Dmitry

> Thanks
> Vivek

Re: [RFC 1/1] ima: digital signature verification using asymmetric keys

[Vivek Goyal]

On Tue, Jan 29, 2013 at 10:48:00AM +0200, Kasatkin, Dmitry wrote:
> On Mon, Jan 28, 2013 at 8:52 PM, Vivek Goyal <vgoyal@redhat.com> wrote:
> > On Mon, Jan 28, 2013 at 05:20:20PM +0200, Kasatkin, Dmitry wrote:
> >
> > [..]
> >> > Ok. I am hoping that it will be more than the kernel command line we
> >> > support. In the sense that for digital signatures one needs to parse
> >> > the signature, look at what hash algorithm has been used  and then
> >> > collect the hash accordingly. It is little different then IMA requirement
> >> > of calculating one pre-determine hash for all files.
> >>
> >> Yes... It is obvious. It's coming.
> >> But in general, signer should be aware of requirements and limitation
> >> of the platform.
> >> It is not really a problem...
> >
> > Ok, I have another question. I was looking at your slide deck here.
> >
> > http://selinuxproject.org/~jmorris/lss2011_slides/IMA_EVM_Digital_Signature_Support.pdf
> >
> > Slide 12 mentions that keys are loaded into the kernel from initramfs. If
> > "root" can load any key, what are we protecting against.
> >
> > IOW, what good ima_appraise_tcb policy, which tries to appraise any root
> > owned file.  A root can sign all the files using its own key and load its
> > public key in IMA keyring and then integrity check should pass on all
> > root files.
> >
> > So what's the idea behind digital signature appraisal? By allowing root to
> > unconditionally load the keys in IMA keyring, it seems to circumvent the
> > appraisal mechanism.
> >
> 
> I will answer directly to this email first.
> 'keyctl setperm' command is used to lock keyring from being able to
> add new keys...
> Even root is not able to revert locked keyring to original
> write-permissive mode.
> 
> root@ubuntu:~# cat /proc/keys |grep ima
> 16a4c685 I--Q---     1 perm 3f010000     0     0 keyring   _ima: 2/4
> root@ubuntu:~# keyctl setperm 379897477  0x0b010000
> root@ubuntu:~# keyctl add user testkey "testing1" 379897477
> add_key: Permission denied
> root@ubuntu:~# keyctl setperm 379897477  0x3f010000
> keyctl_setperm: Permission denied
> root@ubuntu:~# cat /proc/keys |grep ima
> 16a4c685 I--Q---     1 perm 0b010000     0     0 keyring   _ima: 3/4

Hi Dmitry,

Ok, thanks for the clarification. So from initramfs we will load the key in
IMA keyring and then lock it down.

So this boils down to trusting initramfs.  So how do we make sure that
initramfs is not compromised in secureboot environment.

As initramfs is generated dynamically, we could not sign it (no private
key on target) hence can not appraise it. So may be we need to lock down
key loading in IMA keyring in secureboot mode and ship kernel with
pre-loaded keys? Or there are other ways which have already handled this
problem.

Thanks
Vivek

Re: [RFC 1/1] ima: digital signature verification using asymmetric keys

[Vivek Goyal]

On Mon, Jan 28, 2013 at 05:20:20PM +0200, Kasatkin, Dmitry wrote:

[..]
> > Ok. I am hoping that it will be more than the kernel command line we
> > support. In the sense that for digital signatures one needs to parse
> > the signature, look at what hash algorithm has been used  and then
> > collect the hash accordingly. It is little different then IMA requirement
> > of calculating one pre-determine hash for all files.
> 
> Yes... It is obvious. It's coming.
> But in general, signer should be aware of requirements and limitation
> of the platform.
> It is not really a problem...

One more question. I specified "ima_appraise_tcb" on kernel command line
and I had an unbootable system. It refused to run "init" as it was not
labeled/signed. Is there any policy/way where it appraises only signed
files and does not refuse to open/execute unsigned ones.

Thanks
Vivek

Re: [RFC 1/1] ima: digital signature verification using asymmetric keys

[Mimi Zohar]

On Mon, 2013-01-28 at 13:56 -0500, Vivek Goyal wrote:
> On Mon, Jan 28, 2013 at 05:20:20PM +0200, Kasatkin, Dmitry wrote:
> 
> [..]
> > > Ok. I am hoping that it will be more than the kernel command line we
> > > support. In the sense that for digital signatures one needs to parse
> > > the signature, look at what hash algorithm has been used  and then
> > > collect the hash accordingly. It is little different then IMA requirement
> > > of calculating one pre-determine hash for all files.
> > 
> > Yes... It is obvious. It's coming.
> > But in general, signer should be aware of requirements and limitation
> > of the platform.
> > It is not really a problem...
> 
> One more question. I specified "ima_appraise_tcb" on kernel command line
> and I had an unbootable system. It refused to run "init" as it was not
> labeled/signed. Is there any policy/way where it appraises only signed
> files and does not refuse to open/execute unsigned ones.

The policy defines what needs to be measured/appraised, not the other
way around.  There's nothing preventing you from defining and loading a
different policy, one to your liking, before pivoting root.

thanks,

Mimi

Re: [RFC 1/1] ima: digital signature verification using asymmetric keys

[Vivek Goyal]

On Mon, Jan 28, 2013 at 03:15:49PM -0500, Mimi Zohar wrote:
> On Mon, 2013-01-28 at 13:56 -0500, Vivek Goyal wrote:
> > On Mon, Jan 28, 2013 at 05:20:20PM +0200, Kasatkin, Dmitry wrote:
> > 
> > [..]
> > > > Ok. I am hoping that it will be more than the kernel command line we
> > > > support. In the sense that for digital signatures one needs to parse
> > > > the signature, look at what hash algorithm has been used  and then
> > > > collect the hash accordingly. It is little different then IMA requirement
> > > > of calculating one pre-determine hash for all files.
> > > 
> > > Yes... It is obvious. It's coming.
> > > But in general, signer should be aware of requirements and limitation
> > > of the platform.
> > > It is not really a problem...
> > 
> > One more question. I specified "ima_appraise_tcb" on kernel command line
> > and I had an unbootable system. It refused to run "init" as it was not
> > labeled/signed. Is there any policy/way where it appraises only signed
> > files and does not refuse to open/execute unsigned ones.
> 
> The policy defines what needs to be measured/appraised, not the other
> way around.  There's nothing preventing you from defining and loading a
> different policy, one to your liking, before pivoting root.

Hi Mimi,

By policy you mean ima rules here? So I can either enable default rules
(tcb default rules for appraisal and measurement) by using kernel command
line options or dynamically configure my own rules using /sysfs interface?

If yes, AFAIK, existing inputtable policies do not allow this selective
mode where we do appraisal only on signed executable. That means I shall
have to extend the way policies can be specified so that one specify
that appraise only signed files?

Also given the fact that we allow loading policy from initramfs, root
can rebuild initramfs and change the policy which takes effect over next
reboot. So in priciple this works only when we are trying to impose some
policy on non-root users?

Thanks
Vivek

Re: [RFC 1/1] ima: digital signature verification using asymmetric keys

[Mimi Zohar]

On Mon, 2013-01-28 at 15:22 -0500, Vivek Goyal wrote:
> On Mon, Jan 28, 2013 at 03:15:49PM -0500, Mimi Zohar wrote:
> > On Mon, 2013-01-28 at 13:56 -0500, Vivek Goyal wrote:
> > > On Mon, Jan 28, 2013 at 05:20:20PM +0200, Kasatkin, Dmitry wrote:
> > > 
> > > [..]
> > > > > Ok. I am hoping that it will be more than the kernel command line we
> > > > > support. In the sense that for digital signatures one needs to parse
> > > > > the signature, look at what hash algorithm has been used  and then
> > > > > collect the hash accordingly. It is little different then IMA requirement
> > > > > of calculating one pre-determine hash for all files.
> > > > 
> > > > Yes... It is obvious. It's coming.
> > > > But in general, signer should be aware of requirements and limitation
> > > > of the platform.
> > > > It is not really a problem...
> > > 
> > > One more question. I specified "ima_appraise_tcb" on kernel command line
> > > and I had an unbootable system. It refused to run "init" as it was not
> > > labeled/signed. Is there any policy/way where it appraises only signed
> > > files and does not refuse to open/execute unsigned ones.
> > 
> > The policy defines what needs to be measured/appraised, not the other
> > way around.  There's nothing preventing you from defining and loading a
> > different policy, one to your liking, before pivoting root.
> 
> Hi Mimi,
> 
> By policy you mean ima rules here? So I can either enable default rules
> (tcb default rules for appraisal and measurement) by using kernel command
> line options or dynamically configure my own rules using /sysfs interface?
> 
> If yes, AFAIK, existing inputtable policies do not allow this selective
> mode where we do appraisal only on signed executable. That means I shall
> have to extend the way policies can be specified so that one specify
> that appraise only signed files?

We've just added the ability of defining the method for appraising a
file and defining rules in terms of the filesystem UUID.  Extending the
IMA policy shouldn't be a problem, but I'm not sure how you would go
about adding support for only appraising files with digital signatures.

> Also given the fact that we allow loading policy from initramfs, root
> can rebuild initramfs and change the policy which takes effect over next
> reboot. So in priciple this works only when we are trying to impose some
> policy on non-root users?

The assumption has always been that the initramfs would be measured, for
trusted boot, and appraised, for secure boot, before being executed.

Mimi

Re: [RFC 1/1] ima: digital signature verification using asymmetric keys

[Vivek Goyal]

On Mon, Jan 28, 2013 at 08:48:55PM -0500, Mimi Zohar wrote:

[..]
> > Also given the fact that we allow loading policy from initramfs, root
> > can rebuild initramfs and change the policy which takes effect over next
> > reboot. So in priciple this works only when we are trying to impose some
> > policy on non-root users?
> 
> The assumption has always been that the initramfs would be measured, for
> trusted boot, and appraised, for secure boot, before being executed.

Hi Mimi,

Ok. So for trusted boot, if initramfs is changed it will be detected. For
secureboot, atleast right now initramfs is not signed and appraised. But
I guess it could be added. 

But initramfs is generated by installer and installer does not have
private keys to sign it. So distributions could not sign initramfs.

Thanks
Vivek

Re: [RFC 1/1] ima: digital signature verification using asymmetric keys

[Matthew Garrett]

On Tue, Jan 29, 2013 at 11:58:53AM -0500, Vivek Goyal wrote:
> On Mon, Jan 28, 2013 at 08:48:55PM -0500, Mimi Zohar wrote:
> > The assumption has always been that the initramfs would be measured, for
> > trusted boot, and appraised, for secure boot, before being executed.
> 
> Hi Mimi,
> 
> Ok. So for trusted boot, if initramfs is changed it will be detected. For
> secureboot, atleast right now initramfs is not signed and appraised. But
> I guess it could be added. 
> 
> But initramfs is generated by installer and installer does not have
> private keys to sign it. So distributions could not sign initramfs.

Right, there's a whole range of problems here. The first is that the 
initramfs has to contain the full set of drivers required to boot a 
given piece of hardware, and the precise set required varies between 
machines. Building a truly generic initramfs would result in 
significantly larger images.

There's also an existing expectation that it be possible to break into 
initramfs execution for debugging purposes. Even ignoring that, most 
initramfs implementations aren't expected to be hardened against a user 
inserting shell control characters into the kernel command line. It 
would require significant engineering work to ensure that there's no way 
for an attacker to cause code execution before the key store has been 
locked.

Shipping prebuilt initramfses is also difficult from a release 
engineering perspective. You'd need to keep track of the software 
versions that were included in the initramfs and ensure that the 
initramfs is rebuilt if any of those pieces of software are updated 
between the initramfs being generated and the software being shipped. 
Version skew could cause subtle bugs and also makes license compliance 
difficult.

Finally, portions of the userspace in initramfs may be under licenses 
that require it to be possible for the end user to replace components. 
This isn't a problem as long as the keys in MOK can be used.

There's additional small problems, like the initramfs containing the 
bootsplash theme and users expecting to be able to change that without 
having to generate crypto keys, but that's probably not a showstopper. 
But realistically, the first three problems make it unlikely that most 
distributions will be willing to depend on or ship pre-built initramfs 
images.

-- 
Matthew Garrett | mjg59@srcf.ucam.org

Re: [RFC 1/1] ima: digital signature verification using asymmetric keys

[Mimi Zohar]

On Wed, 2013-01-30 at 06:32 +0000, Matthew Garrett wrote:
> On Tue, Jan 29, 2013 at 11:58:53AM -0500, Vivek Goyal wrote:
> > On Mon, Jan 28, 2013 at 08:48:55PM -0500, Mimi Zohar wrote:
> > > The assumption has always been that the initramfs would be measured, for
> > > trusted boot, and appraised, for secure boot, before being executed.
> > 
> > Hi Mimi,
> > 
> > Ok. So for trusted boot, if initramfs is changed it will be detected. For
> > secureboot, atleast right now initramfs is not signed and appraised. But
> > I guess it could be added. 
> > 
> > But initramfs is generated by installer and installer does not have
> > private keys to sign it. So distributions could not sign initramfs.
> 
> Right, there's a whole range of problems here. The first is that the 
> initramfs has to contain the full set of drivers required to boot a 
> given piece of hardware, and the precise set required varies between 
> machines. Building a truly generic initramfs would result in 
> significantly larger images.
> 
> There's also an existing expectation that it be possible to break into 
> initramfs execution for debugging purposes. Even ignoring that, most 
> initramfs implementations aren't expected to be hardened against a user 
> inserting shell control characters into the kernel command line. It 
> would require significant engineering work to ensure that there's no way 
> for an attacker to cause code execution before the key store has been 
> locked.
> 
> Shipping prebuilt initramfses is also difficult from a release 
> engineering perspective. You'd need to keep track of the software 
> versions that were included in the initramfs and ensure that the 
> initramfs is rebuilt if any of those pieces of software are updated 
> between the initramfs being generated and the software being shipped. 
> Version skew could cause subtle bugs and also makes license compliance 
> difficult.
> 
> Finally, portions of the userspace in initramfs may be under licenses 
> that require it to be possible for the end user to replace components. 
> This isn't a problem as long as the keys in MOK can be used.
> 
> There's additional small problems, like the initramfs containing the 
> bootsplash theme and users expecting to be able to change that without 
> having to generate crypto keys, but that's probably not a showstopper. 
> But realistically, the first three problems make it unlikely that most 
> distributions will be willing to depend on or ship pre-built initramfs 
> images.

Ok.  From an IMA-appraisal perspective, either the contents of the
initramfs have to be signed or the initramfs, itself, must be signed.
Otherwise there is a break in the secure boot chain.  Unfortunately,
unlike the bsdcpio package, which has formats that support extended
attributes, the cpio package does not.

Similar to modules, in order to not break the secure boot signature
chain, the IMA-appraisal and EVM keys can be built into the kernel.
Patches were posted a while ago https://lkml.org/lkml/2012/8/15/376, but
have not been upstreamed.  

evm: initialize the _evm public key keyring
ima: initialize the _ima public keyring
integrity: create and inititialize a keyring with builtin public key
keys: initialize root uid and session keyrings early

These patches will need to be updated to reflect recent keyring changes.

thanks,

Mimi

Re: [RFC 1/1] ima: digital signature verification using asymmetric keys

[Vivek Goyal]

On Mon, Jan 28, 2013 at 08:48:55PM -0500, Mimi Zohar wrote:

[..]
> > Hi Mimi,
> > 
> > By policy you mean ima rules here? So I can either enable default rules
> > (tcb default rules for appraisal and measurement) by using kernel command
> > line options or dynamically configure my own rules using /sysfs interface?
> > 
> > If yes, AFAIK, existing inputtable policies do not allow this selective
> > mode where we do appraisal only on signed executable. That means I shall
> > have to extend the way policies can be specified so that one specify
> > that appraise only signed files?
> 
> We've just added the ability of defining the method for appraising a
> file and defining rules in terms of the filesystem UUID.  Extending the
> IMA policy shouldn't be a problem, but I'm not sure how you would go
> about adding support for only appraising files with digital signatures.

Hi Mimi,

Can we add another field to ima_rule_entry, say .enforcement to control
the behavior of .action. Possible values of .enforcement could be, say.

ALL
SIGNED_ONLY

ALL will be default. And with .action= MEASURE, one could possibly use
.enforcement=SIGNED_ONLY.

Thanks
Vivek

Re: [RFC 1/1] ima: digital signature verification using asymmetric keys

[Mimi Zohar]

On Tue, 2013-01-29 at 13:20 -0500, Vivek Goyal wrote:
> On Mon, Jan 28, 2013 at 08:48:55PM -0500, Mimi Zohar wrote:
> 
> [..]
> > > Hi Mimi,
> > > 
> > > By policy you mean ima rules here? So I can either enable default rules
> > > (tcb default rules for appraisal and measurement) by using kernel command
> > > line options or dynamically configure my own rules using /sysfs interface?
> > > 
> > > If yes, AFAIK, existing inputtable policies do not allow this selective
> > > mode where we do appraisal only on signed executable. That means I shall
> > > have to extend the way policies can be specified so that one specify
> > > that appraise only signed files?
> > 
> > We've just added the ability of defining the method for appraising a
> > file and defining rules in terms of the filesystem UUID.  Extending the
> > IMA policy shouldn't be a problem, but I'm not sure how you would go
> > about adding support for only appraising files with digital signatures.
> 
> Hi Mimi,
> 
> Can we add another field to ima_rule_entry, say .enforcement to control
> the behavior of .action. Possible values of .enforcement could be, say.
> 
> ALL
> SIGNED_ONLY
> 
> ALL will be default. And with .action= MEASURE, one could possibly use
> .enforcement=SIGNED_ONLY.

Other than the .action being '.action=APPRAISE', not 'MEASURE',
something like what you're suggesting, could work.  How about extending
the new 'appraise_type=' option?   The appraise_type enforces a
particular type (eg. hash, signature) of verification. 

option: appraise_type:= [imasig[,signed_only]]
eg. appraise_type=imasig,signed_only

thanks,

Mimi

Re: [RFC 1/1] ima: digital signature verification using asymmetric keys

[Vivek Goyal]

On Tue, Jan 29, 2013 at 03:01:13PM -0500, Mimi Zohar wrote:

[..]
> > Hi Mimi,
> > 
> > Can we add another field to ima_rule_entry, say .enforcement to control
> > the behavior of .action. Possible values of .enforcement could be, say.
> > 
> > ALL
> > SIGNED_ONLY
> > 
> > ALL will be default. And with .action= MEASURE, one could possibly use
> > .enforcement=SIGNED_ONLY.
> 
> Other than the .action being '.action=APPRAISE', not 'MEASURE',
> something like what you're suggesting, could work.  How about extending
> the new 'appraise_type=' option?   The appraise_type enforces a
> particular type (eg. hash, signature) of verification. 
> 
> option: appraise_type:= [imasig[,signed_only]]
> eg. appraise_type=imasig,signed_only

Right. Given the fact that signed_only things work only for appraise, it
probably is better to extend ima_appraise= command line option.

I just wrote something based on linus tree. That is introduce
ima_appraise=enforce_labeled_only.

But I would look at your next branch and try introducing
imasig_signed_only.

In the mean time here is the patch I used. I can now boot my unlabeled
system with "ima_appraise_tcb" and "ima_appraise=enforce_labeled_only".

But somehow my system has slowed down significantly and I can feel
slow boot as well as slow file operations on terminal.

Thanks
Vivek

---
 Documentation/kernel-parameters.txt   |    3 ++-
 security/integrity/ima/ima.h          |    1 +
 security/integrity/ima/ima_appraise.c |    6 ++++++
 3 files changed, 9 insertions(+), 1 deletion(-)

Index: linux-2.6/security/integrity/ima/ima_appraise.c
===================================================================
--- linux-2.6.orig/security/integrity/ima/ima_appraise.c	2013-01-18 01:29:29.000000000 -0500
+++ linux-2.6/security/integrity/ima/ima_appraise.c	2013-01-29 14:56:47.636620835 -0500
@@ -24,6 +24,8 @@ static int __init default_appraise_setup
 		ima_appraise = 0;
 	else if (strncmp(str, "fix", 3) == 0)
 		ima_appraise = IMA_APPRAISE_FIX;
+	else if (strncmp(str, "enforce_labeled_only", 21) == 0)
+		ima_appraise = IMA_APPRAISE_ENFORCE_LABELED_ONLY;
 	return 1;
 }
 
@@ -144,6 +146,10 @@ out:
 			ima_fix_xattr(dentry, iint);
 			status = INTEGRITY_PASS;
 		}
+		if ((ima_appraise & IMA_APPRAISE_ENFORCE_LABELED_ONLY) &&
+		   (status == INTEGRITY_NOLABEL))
+			status = INTEGRITY_PASS;
+
 		integrity_audit_msg(AUDIT_INTEGRITY_DATA, inode, filename,
 				    op, cause, rc, 0);
 	} else {
Index: linux-2.6/security/integrity/ima/ima.h
===================================================================
--- linux-2.6.orig/security/integrity/ima/ima.h	2013-01-18 01:29:29.000000000 -0500
+++ linux-2.6/security/integrity/ima/ima.h	2013-01-29 14:51:25.762610948 -0500
@@ -140,6 +140,7 @@ void ima_delete_rules(void);
 #define IMA_APPRAISE_ENFORCE	0x01
 #define IMA_APPRAISE_FIX	0x02
 #define IMA_APPRAISE_MODULES	0x04
+#define IMA_APPRAISE_ENFORCE_LABELED_ONLY	0x08
 
 #ifdef CONFIG_IMA_APPRAISE
 int ima_appraise_measurement(struct integrity_iint_cache *iint,
Index: linux-2.6/Documentation/kernel-parameters.txt
===================================================================
--- linux-2.6.orig/Documentation/kernel-parameters.txt	2013-01-18 01:29:29.000000000 -0500
+++ linux-2.6/Documentation/kernel-parameters.txt	2013-01-29 14:52:44.455613365 -0500
@@ -1064,7 +1064,8 @@ bytes respectively. Such letter suffixes
 			Set number of hash buckets for inode cache.
 
 	ima_appraise=	[IMA] appraise integrity measurements
-			Format: { "off" | "enforce" | "fix" }
+			Format: { "off" | "enforce" | "fix" |
+				  "enforce_labeled_only}
 			default: "enforce"
 
 	ima_appraise_tcb [IMA]

Re: [RFC 1/1] ima: digital signature verification using asymmetric keys

[Mimi Zohar]

On Tue, 2013-01-29 at 15:10 -0500, Vivek Goyal wrote:
> On Tue, Jan 29, 2013 at 03:01:13PM -0500, Mimi Zohar wrote:
> 
> [..]
> > > Hi Mimi,
> > > 
> > > Can we add another field to ima_rule_entry, say .enforcement to control
> > > the behavior of .action. Possible values of .enforcement could be, say.
> > > 
> > > ALL
> > > SIGNED_ONLY
> > > 
> > > ALL will be default. And with .action= MEASURE, one could possibly use
> > > .enforcement=SIGNED_ONLY.
> > 
> > Other than the .action being '.action=APPRAISE', not 'MEASURE',
> > something like what you're suggesting, could work.  How about extending
> > the new 'appraise_type=' option?   The appraise_type enforces a
> > particular type (eg. hash, signature) of verification. 
> > 
> > option: appraise_type:= [imasig[,signed_only]]
> > eg. appraise_type=imasig,signed_only
> 
> Right. Given the fact that signed_only things work only for appraise, it
> probably is better to extend ima_appraise= command line option.
> 
> I just wrote something based on linus tree. That is introduce
> ima_appraise=enforce_labeled_only.
> 
> But I would look at your next branch and try introducing
> imasig_signed_only.
> 
> In the mean time here is the patch I used. I can now boot my unlabeled
> system with "ima_appraise_tcb" and "ima_appraise=enforce_labeled_only".
> 
> But somehow my system has slowed down significantly and I can feel
> slow boot as well as slow file operations on terminal.

The ima_appraise_tcb attempts to appraise all files owned by root, which
is not what you want.  As signatures do not change, you don't need to be
concerned with updating the hash on file close.  Try replacing the
ima_appraise_tcb policy with this one line policy:

appraise fowner=0 func=BPRM_CHECK appraise_type=imasig

thanks,

Mimi


> ---
>  Documentation/kernel-parameters.txt   |    3 ++-
>  security/integrity/ima/ima.h          |    1 +
>  security/integrity/ima/ima_appraise.c |    6 ++++++
>  3 files changed, 9 insertions(+), 1 deletion(-)
> 
> Index: linux-2.6/security/integrity/ima/ima_appraise.c
> ===================================================================
> --- linux-2.6.orig/security/integrity/ima/ima_appraise.c	2013-01-18 01:29:29.000000000 -0500
> +++ linux-2.6/security/integrity/ima/ima_appraise.c	2013-01-29 14:56:47.636620835 -0500
> @@ -24,6 +24,8 @@ static int __init default_appraise_setup
>  		ima_appraise = 0;
>  	else if (strncmp(str, "fix", 3) == 0)
>  		ima_appraise = IMA_APPRAISE_FIX;
> +	else if (strncmp(str, "enforce_labeled_only", 21) == 0)
> +		ima_appraise = IMA_APPRAISE_ENFORCE_LABELED_ONLY;
>  	return 1;
>  }
> 
> @@ -144,6 +146,10 @@ out:
>  			ima_fix_xattr(dentry, iint);
>  			status = INTEGRITY_PASS;
>  		}
> +		if ((ima_appraise & IMA_APPRAISE_ENFORCE_LABELED_ONLY) &&
> +		   (status == INTEGRITY_NOLABEL))
> +			status = INTEGRITY_PASS;
> +
>  		integrity_audit_msg(AUDIT_INTEGRITY_DATA, inode, filename,
>  				    op, cause, rc, 0);
>  	} else {
> Index: linux-2.6/security/integrity/ima/ima.h
> ===================================================================
> --- linux-2.6.orig/security/integrity/ima/ima.h	2013-01-18 01:29:29.000000000 -0500
> +++ linux-2.6/security/integrity/ima/ima.h	2013-01-29 14:51:25.762610948 -0500
> @@ -140,6 +140,7 @@ void ima_delete_rules(void);
>  #define IMA_APPRAISE_ENFORCE	0x01
>  #define IMA_APPRAISE_FIX	0x02
>  #define IMA_APPRAISE_MODULES	0x04
> +#define IMA_APPRAISE_ENFORCE_LABELED_ONLY	0x08
> 
>  #ifdef CONFIG_IMA_APPRAISE
>  int ima_appraise_measurement(struct integrity_iint_cache *iint,
> Index: linux-2.6/Documentation/kernel-parameters.txt
> ===================================================================
> --- linux-2.6.orig/Documentation/kernel-parameters.txt	2013-01-18 01:29:29.000000000 -0500
> +++ linux-2.6/Documentation/kernel-parameters.txt	2013-01-29 14:52:44.455613365 -0500
> @@ -1064,7 +1064,8 @@ bytes respectively. Such letter suffixes
>  			Set number of hash buckets for inode cache.
> 
>  	ima_appraise=	[IMA] appraise integrity measurements
> -			Format: { "off" | "enforce" | "fix" }
> +			Format: { "off" | "enforce" | "fix" |
> +				  "enforce_labeled_only}
>  			default: "enforce"
> 
>  	ima_appraise_tcb [IMA]
> 

Re: [RFC 0/1] ima/evm: signature verification support using asymmetric keys

[Mimi Zohar]

On Tue, 2013-01-15 at 12:34 +0200, Dmitry Kasatkin wrote:
> Asymmetric keys were introduced in linux-3.7 to verify the signature on signed
> kernel modules.  The asymmetric keys infrastructure abstracts the signature
> verification from the crypto details.  This patch adds IMA/EVM signature
> verification using asymmetric keys.  Support for additional signature
> verification methods can now be delegated to the asymmetric key infrastructure.
> 
> Although the module signature header and the IMA/EVM signature header could
> use the same header format, to minimize the signature length and save space
> in the extended attribute, the IMA/EVM header format is different than the
> module signature header.  The main difference is that the key identifier is
> a sha1[12 - 19] hash of the key modulus and exponent and similar to the current
> implementation. The only purpose is to identify corresponding key in the kernel
> keyring. ima-evm-utils was updated to support the new signature format.

David, are you ok with how support for asymmetric keys is being added to
EVM/IMA-appraisal for verifying signatures?  Any comments?

thanks,

Mimi

Re: [RFC 1/1] ima: digital signature verification using asymmetric keys

[David Howells]

Looks reasonable, I think, so you can add:

	Acked-by: David Howells <dhowells@redhat.com>

David

Re: [RFC 1/1] ima: digital signature verification using asymmetric keys

[Kasatkin, Dmitry]

On Thu, Jan 17, 2013 at 7:52 PM, David Howells <dhowells@redhat.com> wrote:
>
> Looks reasonable, I think, so you can add:
>
>         Acked-by: David Howells <dhowells@redhat.com>
>
> David

Thank you.

Re: [RFC 0/1] ima/evm: signature verification support using asymmetric keys

[David Howells]

Mimi Zohar <zohar@linux.vnet.ibm.com> wrote:

> David, are you ok with how support for asymmetric keys is being added to
> EVM/IMA-appraisal for verifying signatures?  Any comments?

I would also like to have a look at altering your trusted key type[*] to be a
subtype of asymmetric keys so that the asymmetric key type can cover keys from
more sources:

	- Compiled-in keys.
	- Keys from UEFI db.
	- Keys from TPM (ie. the trusted key stuff).
	- Keys loaded by the administrator _if_ they are validated by a key the
	  kernel already has.
	
[*] I believe that that's your asymmetric key type and that your encrypted key
    type is your symmetric key type.

To support this, it may be necessary to make it possible to make the "trusted"
key type name a synonym of the "asymmetric" key type name in some way.

I also have some patches to divorce the module signing public keyring stuff
from module signing and make it a more generic system keyring of trusted keys
that can be used for other purposes (such as IMA and verifying additional
keys) that I shall post shortly.

On top of those patches, I have a series of patches to permit extra keys to be
added from signed PE binaries that can be found here:

http://git.kernel.org/?p=linux/kernel/git/dhowells/linux-modsign.git;a=shortlog;h=refs/heads/devel-pekey

David

Re: [RFC 0/1] ima/evm: signature verification support using asymmetric keys

[Mimi Zohar]

On Thu, 2013-01-17 at 18:03 +0000, David Howells wrote:

> I would also like to have a look at altering your trusted key type[*] to be a
> subtype of asymmetric keys so that the asymmetric key type can cover keys from
> more sources:
> 
> 	- Compiled-in keys.
> 	- Keys from UEFI db.
> 	- Keys from TPM (ie. the trusted key stuff).
> 	- Keys loaded by the administrator _if_ they are validated by a key the
> 	  kernel already has.
> 	
> [*] I believe that that's your asymmetric key type and that your encrypted key
>     type is your symmetric key type.

Both trusted and encrypted keys are random number symmetric keys.
Trusted keys are random number symmetric keys, generated and RSA-sealed
by the TPM.

Mimi