integrity

This version resolves the merge issues resulting from the removal of the nameidata parameter to inode_permission(), by moving the integrity_inode_permission() call from inode_permission() to may_open(), and renaming the hook to integrity_nameidata_check(). The nameidata is needed in order to open and read the file, so that the file can be hashed(a cryptographically strong checksum.)

This patch also fixes the template locking, preventing the template from being freed while being used.

This patch is a redesign of the integrity framework, which address a number of issues, including
- generalizing the measurement API beyond just inode measurements.
- separation of the measurement into distinct collection, appraisal, and commitment phases, for greater flexibility.

Extended Verification Module(EVM) and the Integrity Measurement Architecture(IMA) were originally implemented as an LSM module. Based on discussions on the LSM mailing list, a decision was made that the LSM hooks should only be used to enforce mandatory access control decisions and a new set of hooks should be defined specifically for integrity.

EVM/IMA was limited to verifying and measuring a file's (i.e. an inode) integrity and the metadata associated with it. Current research is looking into other types of integrity measurements. (i.e. "Linux kernel integrity measurement using contextual inspection", by Peter A. Loscocco, Perry W. Wilson, J. Aaron Pendergrass, C. Durward McDonell,
http://doi.acm.org/10.1145/1314354.1314362). As a result, a requirement of the new integrity framework is support for different types of integrity measurements.
This patch provides an integrity framework(api and hooks) and placement of the integrity hooks in the appropriate places in the fs directory. Collecting, appraising, and storing of file and other types of integrity data is supported. Multiple integrity templates, which implement the integrity API, may register themselves. For now, only a single integrity provider can register itself for the integrity hooks. (Support for multiple providers registering themselves for the integrity hooks would require some form of stacking.)

The six integrity hooks are:
nameidata_check_integrity, inode_alloc_integrity, inode_free_integrity, bprm_check_integrity, file_free_integrity, file_mmap

The five integrity API calls provided are:
integrity_must_measure, integrity_collect_measurement, integrity_appraise_measurement, integrity_store_measurement, and integrity_display_template.

The type of integrity data being collected, appraised, stored, or displayed is template dependent.

...

security/integrity/integrity.c new file +4 -0

+int integrity_register_template(const char *template_name,
+				const struct template_operations *template_ops)
+{
+	int template_len;

security/integrity/integrity.c new file +5 -0

+		kfree(entry);
+		return -EINVAL;
+	}
+	strcpy(entry->template_name, template_name);
+	entry->template_ops = template_ops;

...

security/integrity/integrity.h new file +4 -0

+static inline void tget(struct template_list_entry *entry)
+{
+	if (!entry)
+		return;

Quoted 55 lines · On Wed, 12 Nov 2008 22:47:12 -0500 Mimi Zohar <[email protected]> wrote:

This version resolves the merge issues resulting from the removal of the nameidata parameter to inode_permission(), by moving the integrity_inode_permission() call from inode_permission() to may_open(), and renaming the hook to integrity_nameidata_check(). The nameidata is needed in order to open and read the file, so that the file can be hashed(a cryptographically strong checksum.)

This patch also fixes the template locking, preventing the template from being freed while being used.

This patch is a redesign of the integrity framework, which address a number of issues, including
- generalizing the measurement API beyond just inode measurements.
- separation of the measurement into distinct collection, appraisal, and commitment phases, for greater flexibility.

Extended Verification Module(EVM) and the Integrity Measurement Architecture(IMA) were originally implemented as an LSM module. Based on discussions on the LSM mailing list, a decision was made that the LSM hooks should only be used to enforce mandatory access control decisions and a new set of hooks should be defined specifically for integrity.

EVM/IMA was limited to verifying and measuring a file's (i.e. an inode) integrity and the metadata associated with it. Current research is looking into other types of integrity measurements. (i.e. "Linux kernel integrity measurement using contextual inspection", by Peter A. Loscocco, Perry W. Wilson, J. Aaron Pendergrass, C. Durward McDonell,
http://doi.acm.org/10.1145/1314354.1314362). As a result, a requirement of the new integrity framework is support for different types of integrity measurements.
This patch provides an integrity framework(api and hooks) and placement of the integrity hooks in the appropriate places in the fs directory. Collecting, appraising, and storing of file and other types of integrity data is supported. Multiple integrity templates, which implement the integrity API, may register themselves. For now, only a single integrity provider can register itself for the integrity hooks. (Support for multiple providers registering themselves for the integrity hooks would require some form of stacking.)

The six integrity hooks are:
nameidata_check_integrity, inode_alloc_integrity, inode_free_integrity, bprm_check_integrity, file_free_integrity, file_mmap

The five integrity API calls provided are:
integrity_must_measure, integrity_collect_measurement, integrity_appraise_measurement, integrity_store_measurement, and integrity_display_template.

The type of integrity data being collected, appraised, stored, or displayed is template dependent.

...

Quoted 4 lines

security/integrity/integrity.c new file +4 -0

+int integrity_register_template(const char *template_name,
+				const struct template_operations *template_ops)
+{
+	int template_len;

security/integrity/integrity.c line 86

Quoted 10 lines

security/integrity/integrity.c new file +10 -0

+	struct template_list_entry *entry;
+
+	entry = kzalloc(sizeof(*entry), GFP_KERNEL);
+	if (!entry)
+		return -ENOMEM;
+	INIT_LIST_HEAD(&entry->template);
+
+	atomic_set(&entry->refcount, 1);
+	template_len = strlen(template_name);
+	if (template_len > TEMPLATE_NAME_LEN_MAX) {

It would be much neater to perform this check before running kzalloc().

Quoted 9 lines

security/integrity/integrity.c new file +9 -0

+		kfree(entry);
+		return -EINVAL;
+	}
+	strcpy(entry->template_name, template_name);
+	entry->template_ops = template_ops;
+
+	mutex_lock(&integrity_templates_mutex);
+	list_add_rcu(&entry->template, &integrity_templates);
+	mutex_unlock(&integrity_templates_mutex);

security/integrity/integrity.c line 101

Quoted 6 lines

security/integrity/integrity.c new file +6 -0

+	synchronize_rcu();
+
+	return 0;
+}
+
+EXPORT_SYMBOL_GPL(integrity_register_template);

someone forgot to run checkpatch.

Quoted 13 lines

...

security/integrity/integrity.h new file +10 -0

+static inline void tget(struct template_list_entry *entry)
+{
+	if (!entry)
+		return;
+	atomic_inc(&entry->refcount);
+}
+
+static inline void tput(struct template_list_entry *entry)
+{
+	if (!entry)

security/integrity/integrity.h line 31

Quoted 4 lines

security/integrity/integrity.h new file +4 -0

+		return;
+	if (atomic_dec_and_test(&entry->refcount))
+		kfree(entry);
+}

Do these _really_ need to test for a NULL pointer? It's an extra test-n-branch in many fastpaths. It would be better to avoid doing this here, if poss.

This version resolves the merge issues resulting from the removal of the nameidata parameter to inode_permission(), by moving the integrity_inode_permission() call from inode_permission() to may_open(), and renaming the hook to integrity_nameidata_check().

Quoted 4 lines · Mimi Zohar

This version resolves the merge issues resulting from the removal of the nameidata parameter to inode_permission(), by moving the integrity_inode_permission() call from inode_permission() to may_open(), and renaming the hook to integrity_nameidata_check().

Still neither a good parameter nor a good name. If you look at fsdevel you'll see that a patch for the next merged window is already out and in Al's to be applied queue that removes the nameidata there. A strcut path and maybe the MAY_ lookup flags should be enough for you, and a integrity_path_check also sounds like it really does what you want.

Also please merge the last radix tree patch into this one so tat it's possible to review the code that actually goes in instead of replacing a large part of it in a follow-up patch.

Ok. So, instead of integrity_nameidata_check(nd, flags), call it integrity_path_check(path, flags).

Perhaps I'm looking at the wrong vfs tree, but I don't see the changes. Where is fsdevel?

This is a re-release of Integrity Measurement Architecture(IMA) as an independent Linunx Integrity Module(LIM) service provider.

As a LIM integrity provider, IMA implements the new LIM must_measure(), collect_measurement(), store_measurement(), and display_template() API calls. The store_measurement() call supports two types of data, IMA (i.e. file data) and generic template data.

IMA provides hardware (TPM) based measurement and attestation for both files and other types of template measurements. As the Trusted Computing (TPM) model requires, IMA measures all files before they are accessed in any way (on the bprm_check_integrity, nameidata_check_integrity, file_mmap hooks), and commits the measurements to the TPM. In addition, IMA maintains a list of these hash values, which can be used to validate the aggregate PCR value. The TPM can sign these measurements, and thus the system can prove to itself and to a third party these measurements in a way that cannot be circumvented by malicious or compromised software.

When store_measurement() is called for the IMA type of data, the file measurement and the file name hint are used to form an IMA template. IMA then calculates the IMA template measurement(hash) and submits it to the TPM chip for inclusion in one of the chip's Platform Configuration Registers (PCR).

When store_measurement() is called for generic template data, IMA calculates the measurement(hash) of the template data, and submits the template measurement to the TPM chip for inclusion in one of the chip's Platform Configuration Registers(PCR).

In order to view the contents of template data through securityfs, the template_display() function must be defined in the registered template_operations. In the case of the IMA template, the list of file names and files hashes submitted can be viewed through securityfs.

As mentioned above, IMA maintains a list of hash values of executables and other sensitive system files loaded into the run-time of the system. Our work has shown that requests for integrity appraisal and measurement need to be based on knowledge of the filesystem, requiring the system to either be labeled with integrity data or depend on the existent LSM security labels. The previous set of integrity patches modified the LSM modules to be integrity context aware, meaning that the LSM modules made integrity data/metadata appraisal and measurement API calls based on an understanding of the LSM security labels. Both of the LSM maintainers felt that the changes were too intrusive and that integrity enforcement should be made by the integrity provider, not the LSM module.

To address these concerns, Stephen Smalley suggested using the security_audit_rule_match(), renamed to security_filter_rule_match(), to define LSM specific integrity measurement policy rules, in lieu of modifying the LSM modules. In the current set of patches, the integrity API calls can be made either by IMA, based on an LSM specific integrity policy, or by an integrity context aware LSM.

...

Quoted 55 lines · On Wed, 12 Nov 2008 22:47:13 -0500 Mimi Zohar <[email protected]> wrote:

This is a re-release of Integrity Measurement Architecture(IMA) as an independent Linunx Integrity Module(LIM) service provider.

As a LIM integrity provider, IMA implements the new LIM must_measure(), collect_measurement(), store_measurement(), and display_template() API calls. The store_measurement() call supports two types of data, IMA (i.e. file data) and generic template data.

IMA provides hardware (TPM) based measurement and attestation for both files and other types of template measurements. As the Trusted Computing (TPM) model requires, IMA measures all files before they are accessed in any way (on the bprm_check_integrity, nameidata_check_integrity, file_mmap hooks), and commits the measurements to the TPM. In addition, IMA maintains a list of these hash values, which can be used to validate the aggregate PCR value. The TPM can sign these measurements, and thus the system can prove to itself and to a third party these measurements in a way that cannot be circumvented by malicious or compromised software.

When store_measurement() is called for the IMA type of data, the file measurement and the file name hint are used to form an IMA template. IMA then calculates the IMA template measurement(hash) and submits it to the TPM chip for inclusion in one of the chip's Platform Configuration Registers (PCR).

When store_measurement() is called for generic template data, IMA calculates the measurement(hash) of the template data, and submits the template measurement to the TPM chip for inclusion in one of the chip's Platform Configuration Registers(PCR).

In order to view the contents of template data through securityfs, the template_display() function must be defined in the registered template_operations. In the case of the IMA template, the list of file names and files hashes submitted can be viewed through securityfs.

As mentioned above, IMA maintains a list of hash values of executables and other sensitive system files loaded into the run-time of the system. Our work has shown that requests for integrity appraisal and measurement need to be based on knowledge of the filesystem, requiring the system to either be labeled with integrity data or depend on the existent LSM security labels. The previous set of integrity patches modified the LSM modules to be integrity context aware, meaning that the LSM modules made integrity data/metadata appraisal and measurement API calls based on an understanding of the LSM security labels. Both of the LSM maintainers felt that the changes were too intrusive and that integrity enforcement should be made by the integrity provider, not the LSM module.

To address these concerns, Stephen Smalley suggested using the security_audit_rule_match(), renamed to security_filter_rule_match(), to define LSM specific integrity measurement policy rules, in lieu of modifying the LSM modules. In the current set of patches, the integrity API calls can be made either by IMA, based on an LSM specific integrity policy, or by an integrity context aware LSM.

...

security/integrity/ima/ima_init.c line 35

Quoted 9 lines

security/integrity/ima/ima_init.c new file +9 -0

+static void ima_add_boot_aggregate(void)
+{
+	/* cumulative sha1 over tpm registers 0-7 */
+	struct ima_measure_entry *entry;
+	size_t count;
+	int err;
+
+	/* create new entry for boot aggregate */
+	entry = kzalloc(sizeof(*entry), GFP_ATOMIC);

This uses GFP_ATOMIC, but crypto_alloc_hash() (called later) uses GFP_KERNEL.

If this _had_ to be GFP_ATOMIC then you have a bug.

Otherwise, please use the much more reliable GFP_KERNEL here.

This version stores integrity information associated with an inode in a radix tree in order to avoid bloating the in memory inode. As entries can not be added to the radix tree at security_initcall, this version removes the dual stage initialization. Allocating and freeing the memory continues to be done at inode_alloc and file_free, respectively, except for inodes created before late_initcall.

Signed-off-by Mimi Zohar <[email protected]>

---

include/linux/fs.h +0 -0

index bc6460c..0dcdd94 100644

include/linux/fs.h +0 -0

 	void			*i_private; /* fs or device private pointer */
 };
 

security/integrity/ima/Makefile +1 -1

index f3aced4..959ae66 100644
@@ -6,4 +6,4 @@
 obj-$(CONFIG_IMA) += ima.o
 
 ima-y := ima_fs.o ima_queue.o ima_init.o ima_main.o ima_crypto.o ima_api.o \
-	 ima_policy.o
+	 ima_policy.o ima_iint.o

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

index 9a24305..09a5e1a 100644
@@ -92,7 +92,6 @@ void ima_store_measurement(void *d);
 void ima_template_show(struct seq_file *m, void *e,
 		       enum integrity_show_type show);
 
-
 /*
  * used to protect h_table and sha_table
  */

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

 }
 
 /* TPM "Glue" definitions */

@@ -145,11 +144,36 @@ struct ima_iint_cache {
 	u8 hmac[IMA_DIGEST_SIZE];

...

security/integrity/ima/ima_iint.c new file +17 -0

@@ -0,0 +1,68 @@
+/*
+ * Copyright (C) 2008 IBM Corporation
+ *
+ * Authors:
+ * Mimi Zohar <[email protected]>
+ *
+ * This program is free software; you can redistribute it and/or
+ * modify it under the terms of the GNU General Public License as
+ * published by the Free Software Foundation, version 2 of the
+ * License.
+ *
+ * File: ima_iint.c
+ *             cache integrity information associated with an inode
+ *             using a radix tree.
+ */
+#include <linux/module.h>
+#include <linux/spinlock.h>

Quoted 7 lines · On Wed, 12 Nov 2008 22:47:14 -0500 Mimi Zohar <[email protected]> wrote:

This version stores integrity information associated with an inode in a radix tree in order to avoid bloating the in memory inode. As entries can not be added to the radix tree at security_initcall, this version removes the dual stage initialization. Allocating and freeing the memory continues to be done at inode_alloc and file_free, respectively, except for inodes created before late_initcall.

include/linux/fs.h struct inode { · line 688

Quoted 13 lines

Signed-off-by Mimi Zohar <[email protected]>

---

include/linux/fs.h +0 -3

index bc6460c..0dcdd94 100644
@@ -683,9 +683,6 @@ struct inode {
 #ifdef CONFIG_SECURITY
 	void			*i_security;
 #endif
-#ifdef CONFIG_INTEGRITY
-	void			*i_integrity;
-#endif

ah, I was going to ask about that..

Quoted 27 lines

include/linux/fs.h +0 -0

 	void			*i_private; /* fs or device private pointer */
 };
 

security/integrity/ima/Makefile +1 -1

index f3aced4..959ae66 100644
@@ -6,4 +6,4 @@
 obj-$(CONFIG_IMA) += ima.o
 
 ima-y := ima_fs.o ima_queue.o ima_init.o ima_main.o ima_crypto.o ima_api.o \
-	 ima_policy.o
+	 ima_policy.o ima_iint.o

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

index 9a24305..09a5e1a 100644
@@ -92,7 +92,6 @@ void ima_store_measurement(void *d);
 void ima_template_show(struct seq_file *m, void *e,
 		       enum integrity_show_type show);
 
-
 /*
  * used to protect h_table and sha_table
  */

@@ -109,7 +108,7 @@ extern struct ima_h_table ima_htable;
 

security/integrity/ima/ima.h extern struct ima_h_table ima_htable; · line 111

Quoted 4 lines

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

 static inline unsigned long IMA_HASH_KEY(u8 *digest)
 {
-	 return(hash_long(*digest, IMA_HASH_BITS));
+	return (hash_long(*digest, IMA_HASH_BITS));

And I _did_ ask about that ;)

Quoted 5 lines

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

 }
 
 /* TPM "Glue" definitions */

@@ -145,11 +144,36 @@ struct ima_iint_cache {
 	u8 hmac[IMA_DIGEST_SIZE];

security/integrity/ima/ima.h struct ima_iint_cache { · line 154

Quoted 10 lines

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

 	u8 digest[IMA_DIGEST_SIZE];
 	struct mutex mutex;
+	atomic_t refcount;
 };
 #define IMA_IINT_INIT		1
 #define IMA_MUST_MEASURE	2
 #define IMA_MEASURED		4
 
+void ima_iint_init(void);
+struct ima_iint_cache * ima_iint_lookup(struct inode *inode);

checkpatch...

Quoted 27 lines

...

security/integrity/ima/ima_iint.c new file +21 -0

@@ -0,0 +1,68 @@
+/*
+ * Copyright (C) 2008 IBM Corporation
+ *
+ * Authors:
+ * Mimi Zohar <[email protected]>
+ *
+ * This program is free software; you can redistribute it and/or
+ * modify it under the terms of the GNU General Public License as
+ * published by the Free Software Foundation, version 2 of the
+ * License.
+ *
+ * File: ima_iint.c
+ *             cache integrity information associated with an inode
+ *             using a radix tree.
+ */
+#include <linux/module.h>
+#include <linux/spinlock.h>
+#include <linux/radix-tree.h>
+#include "ima.h"
+
+static struct radix_tree_root ima_iint_store;

security/integrity/ima/ima_iint.c line 27

Quoted 6 lines

security/integrity/ima/ima_iint.c new file +6 -0

+DEFINE_SPINLOCK(ima_iint_lock);
+
+void ima_iint_init(void)
+{
+	INIT_RADIX_TREE(&ima_iint_store, GFP_ATOMIC);
+}

Use the RADIX_TREE() macro, then remove this function.

The Linux Integrity Module (LIM) Framework provides hooks for modules to perform collection, appraisal, and storage of system integrity measurements. One such module, IMA, collects measurements of file data, maintains this list in the kernel, and if available, stores (extends) the measurements into a hardware TPM. These measurements are collected, appraised, and stored before any access (read or execute) to the data, so that malicious code or data cannot remove or cover up its own measurement, to avoid detection. If the measurements are anchored in a TPM, the TPM can sign the measurements, for proof of integrity to a third party, such as in enterprise client management.

Integrity measurement is complementary to LSM mandatory access control, which can be used to protect the integrity of system files. Integrity measurement policies can take advantage of LSM labels in deciding what to measure and to detect when the protection fails, with hardware strength.

Quoted 2 lines · On Wed, 12 Nov 2008 22:47:10 -0500 Mimi Zohar <[email protected]> wrote:

The Linux Integrity Module (LIM) Framework provides hooks
...

This all looks quite mergeable to me, although I am far from being an expert on security things.

One thing which I cannot say, and which is quite important: how useful will all of this be to our users? Are people asking for it? Are people likely to enable and use it? Are they even likely to understand it? ;) Are any large/important customers asking for it? Are distros likely to enable and support it?

One thing which I cannot say, and which is quite important: how useful will all of this be to our users? Are people asking for it?

Are
people likely to enable and use it? Are they even likely to understand it? ;) Are any large/important customers asking for it? Are distros likely to enable and support it?