ima/evm: signature verification support using asymmetric keys

Looks reasonable, I think, so you can add:

Acked-by David Howells <[email protected]>

David

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 <[email protected]>

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

security/integrity/Kconfig +12 -0

index 5bd1cc1..19c4187 100644
@@ -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

security/integrity/digsig.c +97 -0

index 2dc167d..1896537 100644
@@ -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;

Quoted 163 lines · 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 <[email protected]>

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

security/integrity/Kconfig +12 -0

index 5bd1cc1..19c4187 100644
@@ -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

security/integrity/digsig.c +101 -1

index 2dc167d..1896537 100644
@@ -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);

security/integrity/digsig.c int integrity_digsig_verify(const unsigned int id, const char *sig, int siglen, · line 149

Quoted 3 lines

security/integrity/digsig.c +1 -0

+#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

--
To unsubscribe from this list: send the line "unsubscribe linux-security-module" in the body of a message to [email protected]
More majordomo info at http://vger.kernel.org/majordomo-info.html

Quoted 164 lines · Mimi Zohar

Quoted 163 lines · 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 <[email protected]>

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

security/integrity/Kconfig +12 -0

index 5bd1cc1..19c4187 100644
@@ -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

security/integrity/digsig.c +101 -1

index 2dc167d..1896537 100644
@@ -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);

Quoted 9 lines

security/integrity/digsig.c int integrity_digsig_verify(const unsigned int id, const char *sig, int siglen, · line 149

Quoted 3 lines

security/integrity/digsig.c +1 -0

+#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

Quoted 10 lines

thanks,

Mimi

--
To unsubscribe from this list: send the line "unsubscribe linux-security-module" in the body of a message to [email protected]
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 [email protected]
More majordomo info at http://vger.kernel.org/majordomo-info.html

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

Quoted 193 lines · Dmitry

Quoted 164 lines · Mimi Zohar

Quoted 163 lines · 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 <[email protected]>

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

security/integrity/Kconfig +12 -0

index 5bd1cc1..19c4187 100644
@@ -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

security/integrity/digsig.c +101 -1

index 2dc167d..1896537 100644
@@ -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);

Quoted 9 lines

security/integrity/digsig.c int integrity_digsig_verify(const unsigned int id, const char *sig, int siglen, · line 149

Quoted 3 lines

security/integrity/digsig.c +1 -0

+#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

Quoted 10 lines

thanks,

Mimi

--
To unsubscribe from this list: send the line "unsubscribe linux-security-module" in the body of a message to [email protected]
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 [email protected]
More majordomo info at http://vger.kernel.org/majordomo-info.html

Quoted 8 lines · 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.

Quoted 7 lines

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.

Quoted 17 lines · Dmitry

Quoted 8 lines · 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.

Quoted 7 lines

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.

Quoted 6 lines

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

Quoted 5 lines

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

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

[..]

Quoted 10 lines

Quoted 5 lines

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.

Quoted 21 lines · Vivek Goyal

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

[..]

Quoted 10 lines

Quoted 5 lines

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.

Quoted 8 lines

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.

Quoted 31 lines · Mimi Zohar

Quoted 21 lines · Vivek Goyal

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

[..]

Quoted 10 lines

Quoted 5 lines

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.

Quoted 8 lines

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.

Quoted 7 lines

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.

Quoted 7 lines

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.

Quoted 3 lines

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.

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?

Quoted 31 lines · Mimi Zohar

Quoted 21 lines · Vivek Goyal

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

[..]

Quoted 10 lines

Quoted 5 lines

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.

Quoted 8 lines

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.

Quoted 7 lines

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.

Quoted 11 lines

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

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

[..]

Quoted 10 lines

Quoted 5 lines

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

Quoted 21 lines · Vivek Goyal

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

[..]

Quoted 10 lines

Quoted 5 lines

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.

Quoted 9 lines

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

Quoted 5 lines

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

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

[..]

Quoted 10 lines

Quoted 5 lines

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.

Quoted 14 lines · Vivek Goyal

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

[..]

Quoted 10 lines

Quoted 5 lines

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

Quoted 4 lines

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.

Quoted 15 lines · Mimi Zohar

Quoted 14 lines · Vivek Goyal

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

[..]

Quoted 10 lines

Quoted 5 lines

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

Quoted 8 lines

Quoted 4 lines

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?

Quoted 4 lines

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.

Quoted 2 lines · Mimi Zohar

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.

Quoted 4 lines · Vivek Goyal

Quoted 2 lines · Mimi Zohar

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

Quoted 8 lines

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.

Quoted 10 lines

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.

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

[..]

Quoted 11 lines

Quoted 10 lines

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?

Quoted 4 lines

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.

Quoted 10 lines

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

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

[..]

Quoted 11 lines

Quoted 10 lines

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.

Quoted 7 lines

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.

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

security/integrity/ima/ima_appraise.c +6 -0

@@ -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
===================================================================

security/integrity/ima/ima.h +1 -0

@@ -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
===================================================================

Documentation/kernel-parameters.txt +2 -1

@@ -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]

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?

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.