linux-integrity.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
* [PATCH v10 0/8] IMA: support for measuring kernel integrity critical data
@ 2021-01-08  4:07 Tushar Sugandhi
  2021-01-08  4:07 ` [PATCH v10 1/8] IMA: generalize keyring specific measurement constructs Tushar Sugandhi
                   ` (8 more replies)
  0 siblings, 9 replies; 28+ messages in thread
From: Tushar Sugandhi @ 2021-01-08  4:07 UTC (permalink / raw)
  To: zohar, stephen.smalley.work, casey, agk, snitzer, gmazyland, paul
  Cc: tyhicks, sashal, jmorris, nramas, linux-integrity, selinux,
	linux-security-module, linux-kernel, dm-devel

IMA measures files and buffer data such as keys, command-line arguments
passed to the kernel on kexec system call, etc.  While these measurements
are necessary for monitoring and validating the integrity of the system,
they are not sufficient.  Various data structures, policies, and states
stored in kernel memory also impact the integrity of the system.
Several kernel subsystems contain such integrity critical data -
e.g.  LSMs like SELinux, AppArmor etc.  or device-mapper targets like
dm-crypt, dm-verity, dm-integrity etc.  These kernel subsystems help
protect the integrity of a system.  Their integrity critical data is not
expected to change frequently during run-time.  Some of these structures
cannot be defined as __ro_after_init, because they are initialized later.

For a given system, various external services/infrastructure tools
(including the attestation service) interact with it - both during the
setup and during rest of the system run-time.  They share sensitive data
and/or execute critical workload on that system.  The external services
may want to verify the current run-time state of the relevant kernel
subsystems before fully trusting the system with business critical
data/workload.  For instance, verifying that SELinux is in "enforce" mode
along with the expected policy, disks are encrypted with a certain
configuration, secure boot is enabled etc.

This series provides the necessary IMA functionality for kernel
subsystems to ensure their configuration can be measured:
  - by kernel subsystems themselves,
  - in a tamper resistant way,
  - and re-measured - triggered on state/configuration change.

This patch set:
  - defines a new IMA hook ima_measure_critical_data() to measure
    integrity critical data,
  - limits the critical data being measured based on a label,
  - defines a builtin critical data measurement policy,
  - and includes an SELinux consumer of the new IMA critical data hook.

This series is based on the following repo/branch:

 repo: https://git.kernel.org/pub/scm/linux/kernel/git/zohar/linux-integrity.git
 branch: next-integrity
 commit 207cdd565dfc ("ima: Don't modify file descriptor mode on the fly")

Change Log v10:
Incorporated feedback from Mimi on v9 of this series.
 - Updated function description comments to simplify language and remove
   unnecessary text.
 - Changed references to variable names and policy documentation from
   "data_source" to "label".
 - Updated patch descriptions to simplify language and remove unnecessary
   text.
 - Updated function names and file name related to SELinux IMA
   measurements per feedback from Paul Moore.
 - Updated patch description for adding a built-in IMA policy for
   measuring kernel critical data.

Change Log v9:
Incorporated feedback from Tyler on v8 of this series.
 - Moved rule->data_source logic from Patch #4 to Patch #5.
 - Removed unnecessary variable event_name from selinux_event_name()
   in Patch #8.


Change Log v8:
Incorporated feedback from Tyler on v7 of this series.
 - Removed unnecessary 'else' clauses in ima_match_rule_data().
 - Fixed ima_store_template() to pass the buffer hash in case the
   buffer is large.
 - fixed function description for ima_measure_critical_data().
 - Moved some usage of CRITICAL_DATA from Patch #3 to Patch #4.
 - Moved IMA_DATA_SOURCE from Patch #4 to Patch #5.
 - Removed unnecessary pr_err() from ima_measure_critical_data()
   and selinux_event_name().
 - Fixed log formatting in selinux_measure_state() to be consistent
   with other messages in that file.

Change Log v7:
Incorporated feedback from Mimi on v6 of this series.
 - Updated cover letter and patch descriptions as per Mimi's feedback.
 - Changed references to variable names and policy documentation from
   plural "data_sources" to singular "data_source".
 - Updated SELinux patch to measure only policy, instead of policy and
   state.  The state measurement will be upstreamed through a separate
   patch.
 - Updated admin-guide/kernel-parameters.txt to document support for
   critical_data in builtin policy.

Change Log v6:
Incorporated feedback from Mimi on v5 of this series.
 - Got rid of patch 5 from the v5 of the series.(the allow list for data
   sources)
 - Updated function descriptions, changed variable names etc.
 - Moved the input param event_data_source in ima_measure_critical_data()
   to a new patch.  (patch 6/8 of this series)
 - Split patch 4 from v5 of the series into two patches (patch 4/8 and 
   patch 5/8)
 - Updated cover letter and patch descriptions as per feedback.

Change Log v5:
(1) Incorporated feedback from Stephen on the last SeLinux patch.
 SeLinux Patch: https://patchwork.kernel.org/patch/11801585/
 - Freed memory in the reverse order of allocation in 
   selinux_measure_state().
 - Used scnprintf() instead of snprintf() to create the string for
   selinux state.
 - Allocated event name passed to ima_measure_critical_data() before
   gathering selinux state and policy information for measuring.

(2) Incorporated feedback from Mimi on v4 of this series.
 V4 of this Series: https://patchwork.kernel.org/project/linux-integrity/list/?series=354437

 - Removed patch "[v4,2/6] IMA: conditionally allow empty rule data"
 - Reversed the order of following patches.
      [v4,4/6] IMA: add policy to measure critical data from kernel components
      [v4,5/6] IMA: add hook to measure critical data from kernel components
   and renamed them to remove "from kernel components"
 - Added a new patch to this series - 
       IMA: add critical_data to built-in policy rules

 - Added the next version of SeLinux patch (mentioned above) to this
   series 
       selinux: measure state and hash of the policy using IMA

 - Updated cover-letter description to give broader perspective of the
   feature, rearranging paragraphs, removing unnecessary info, clarifying
   terms etc.
 - Got rid of opt_list param from ima_match_rule_data().
 - Updated the documentation to remove sources that don't yet exist.
 - detailed IMA hook description added to ima_measure_critical_data(),
   as well as elaborating terms event_name, event_data_source.
 - "data_sources:=" is not a mandatory policy option for 
   func=CRITICAL_DATA anymore.  If not present, all the data sources
   specified in __ima_supported_kernel_data_sources will be measured.


Lakshmi Ramasubramanian (2):
  IMA: define a builtin critical data measurement policy
  selinux: include a consumer of the new IMA critical data hook

Tushar Sugandhi (6):
  IMA: generalize keyring specific measurement constructs
  IMA: add support to measure buffer data hash
  IMA: define a hook to measure kernel integrity critical data
  IMA: add policy rule to measure critical data
  IMA: limit critical data measurement based on a label
  IMA: extend critical data hook to limit the measurement based on a
    label

 Documentation/ABI/testing/ima_policy          |   5 +-
 .../admin-guide/kernel-parameters.txt         |   5 +-
 include/linux/ima.h                           |  10 ++
 security/integrity/ima/ima.h                  |   8 +-
 security/integrity/ima/ima_api.c              |   8 +-
 security/integrity/ima/ima_appraise.c         |   2 +-
 security/integrity/ima/ima_asymmetric_keys.c  |   2 +-
 security/integrity/ima/ima_main.c             |  59 +++++++--
 security/integrity/ima/ima_policy.c           | 115 ++++++++++++++----
 security/integrity/ima/ima_queue_keys.c       |   3 +-
 security/selinux/Makefile                     |   2 +
 security/selinux/ima.c                        |  64 ++++++++++
 security/selinux/include/ima.h                |  24 ++++
 security/selinux/include/security.h           |   3 +-
 security/selinux/ss/services.c                |  64 ++++++++--
 15 files changed, 324 insertions(+), 50 deletions(-)
 create mode 100644 security/selinux/ima.c
 create mode 100644 security/selinux/include/ima.h

-- 
2.17.1


^ permalink raw reply	[flat|nested] 28+ messages in thread

* [PATCH v10 1/8] IMA: generalize keyring specific measurement constructs
  2021-01-08  4:07 [PATCH v10 0/8] IMA: support for measuring kernel integrity critical data Tushar Sugandhi
@ 2021-01-08  4:07 ` Tushar Sugandhi
  2021-01-08  4:07 ` [PATCH v10 2/8] IMA: add support to measure buffer data hash Tushar Sugandhi
                   ` (7 subsequent siblings)
  8 siblings, 0 replies; 28+ messages in thread
From: Tushar Sugandhi @ 2021-01-08  4:07 UTC (permalink / raw)
  To: zohar, stephen.smalley.work, casey, agk, snitzer, gmazyland, paul
  Cc: tyhicks, sashal, jmorris, nramas, linux-integrity, selinux,
	linux-security-module, linux-kernel, dm-devel

IMA functions such as ima_match_keyring(), process_buffer_measurement(),
ima_match_policy() etc.  handle data specific to keyrings.  Currently,
these constructs are not generic to handle any func specific data.
This makes it harder to extend them without code duplication.

Refactor the keyring specific measurement constructs to be generic and
reusable in other measurement scenarios.

Signed-off-by: Tushar Sugandhi <tusharsu@linux.microsoft.com>
Reviewed-by: Tyler Hicks <tyhicks@linux.microsoft.com>
---
 security/integrity/ima/ima.h        |  6 ++--
 security/integrity/ima/ima_api.c    |  6 ++--
 security/integrity/ima/ima_main.c   |  6 ++--
 security/integrity/ima/ima_policy.c | 43 +++++++++++++++++------------
 4 files changed, 35 insertions(+), 26 deletions(-)

diff --git a/security/integrity/ima/ima.h b/security/integrity/ima/ima.h
index 8e8b1e3cb847..e5622ce8cbb1 100644
--- a/security/integrity/ima/ima.h
+++ b/security/integrity/ima/ima.h
@@ -256,7 +256,7 @@ static inline void ima_process_queued_keys(void) {}
 int ima_get_action(struct inode *inode, const struct cred *cred, u32 secid,
 		   int mask, enum ima_hooks func, int *pcr,
 		   struct ima_template_desc **template_desc,
-		   const char *keyring);
+		   const char *func_data);
 int ima_must_measure(struct inode *inode, int mask, enum ima_hooks func);
 int ima_collect_measurement(struct integrity_iint_cache *iint,
 			    struct file *file, void *buf, loff_t size,
@@ -268,7 +268,7 @@ void ima_store_measurement(struct integrity_iint_cache *iint, struct file *file,
 			   struct ima_template_desc *template_desc);
 void process_buffer_measurement(struct inode *inode, const void *buf, int size,
 				const char *eventname, enum ima_hooks func,
-				int pcr, const char *keyring);
+				int pcr, const char *func_data);
 void ima_audit_measurement(struct integrity_iint_cache *iint,
 			   const unsigned char *filename);
 int ima_alloc_init_template(struct ima_event_data *event_data,
@@ -284,7 +284,7 @@ const char *ima_d_path(const struct path *path, char **pathbuf, char *filename);
 int ima_match_policy(struct inode *inode, const struct cred *cred, u32 secid,
 		     enum ima_hooks func, int mask, int flags, int *pcr,
 		     struct ima_template_desc **template_desc,
-		     const char *keyring);
+		     const char *func_data);
 void ima_init_policy(void);
 void ima_update_policy(void);
 void ima_update_policy_flag(void);
diff --git a/security/integrity/ima/ima_api.c b/security/integrity/ima/ima_api.c
index 4f39fb93f278..e76499b1ce78 100644
--- a/security/integrity/ima/ima_api.c
+++ b/security/integrity/ima/ima_api.c
@@ -170,7 +170,7 @@ void ima_add_violation(struct file *file, const unsigned char *filename,
  * @func: caller identifier
  * @pcr: pointer filled in if matched measure policy sets pcr=
  * @template_desc: pointer filled in if matched measure policy sets template=
- * @keyring: keyring name used to determine the action
+ * @func_data: func specific data, may be NULL
  *
  * The policy is defined in terms of keypairs:
  *		subj=, obj=, type=, func=, mask=, fsmagic=
@@ -186,14 +186,14 @@ void ima_add_violation(struct file *file, const unsigned char *filename,
 int ima_get_action(struct inode *inode, const struct cred *cred, u32 secid,
 		   int mask, enum ima_hooks func, int *pcr,
 		   struct ima_template_desc **template_desc,
-		   const char *keyring)
+		   const char *func_data)
 {
 	int flags = IMA_MEASURE | IMA_AUDIT | IMA_APPRAISE | IMA_HASH;
 
 	flags &= ima_policy_flag;
 
 	return ima_match_policy(inode, cred, secid, func, mask, flags, pcr,
-				template_desc, keyring);
+				template_desc, func_data);
 }
 
 /*
diff --git a/security/integrity/ima/ima_main.c b/security/integrity/ima/ima_main.c
index 68956e884403..b4ed611cd2a4 100644
--- a/security/integrity/ima/ima_main.c
+++ b/security/integrity/ima/ima_main.c
@@ -786,13 +786,13 @@ int ima_post_load_data(char *buf, loff_t size,
  * @eventname: event name to be used for the buffer entry.
  * @func: IMA hook
  * @pcr: pcr to extend the measurement
- * @keyring: keyring name to determine the action to be performed
+ * @func_data: func specific data, may be NULL
  *
  * Based on policy, the buffer is measured into the ima log.
  */
 void process_buffer_measurement(struct inode *inode, const void *buf, int size,
 				const char *eventname, enum ima_hooks func,
-				int pcr, const char *keyring)
+				int pcr, const char *func_data)
 {
 	int ret = 0;
 	const char *audit_cause = "ENOMEM";
@@ -831,7 +831,7 @@ void process_buffer_measurement(struct inode *inode, const void *buf, int size,
 	if (func) {
 		security_task_getsecid(current, &secid);
 		action = ima_get_action(inode, current_cred(), secid, 0, func,
-					&pcr, &template, keyring);
+					&pcr, &template, func_data);
 		if (!(action & IMA_MEASURE))
 			return;
 	}
diff --git a/security/integrity/ima/ima_policy.c b/security/integrity/ima/ima_policy.c
index 823a0c1379cb..b93966034368 100644
--- a/security/integrity/ima/ima_policy.c
+++ b/security/integrity/ima/ima_policy.c
@@ -453,30 +453,40 @@ int ima_lsm_policy_change(struct notifier_block *nb, unsigned long event,
 }
 
 /**
- * ima_match_keyring - determine whether the keyring matches the measure rule
+ * ima_match_rule_data - determine whether func_data matches the policy rule
  * @rule: a pointer to a rule
- * @keyring: name of the keyring to match against the measure rule
+ * @func_data: data to match against the measure rule data
  * @cred: a pointer to a credentials structure for user validation
  *
- * Returns true if keyring matches one in the rule, false otherwise.
+ * Returns true if func_data matches one in the rule, false otherwise.
  */
-static bool ima_match_keyring(struct ima_rule_entry *rule,
-			      const char *keyring, const struct cred *cred)
+static bool ima_match_rule_data(struct ima_rule_entry *rule,
+				const char *func_data,
+				const struct cred *cred)
 {
+	const struct ima_rule_opt_list *opt_list = NULL;
 	bool matched = false;
 	size_t i;
 
 	if ((rule->flags & IMA_UID) && !rule->uid_op(cred->uid, rule->uid))
 		return false;
 
-	if (!rule->keyrings)
-		return true;
+	switch (rule->func) {
+	case KEY_CHECK:
+		if (!rule->keyrings)
+			return true;
+
+		opt_list = rule->keyrings;
+		break;
+	default:
+		return false;
+	}
 
-	if (!keyring)
+	if (!func_data)
 		return false;
 
-	for (i = 0; i < rule->keyrings->count; i++) {
-		if (!strcmp(rule->keyrings->items[i], keyring)) {
+	for (i = 0; i < opt_list->count; i++) {
+		if (!strcmp(opt_list->items[i], func_data)) {
 			matched = true;
 			break;
 		}
@@ -493,20 +503,20 @@ static bool ima_match_keyring(struct ima_rule_entry *rule,
  * @secid: the secid of the task to be validated
  * @func: LIM hook identifier
  * @mask: requested action (MAY_READ | MAY_WRITE | MAY_APPEND | MAY_EXEC)
- * @keyring: keyring name to check in policy for KEY_CHECK func
+ * @func_data: func specific data, may be NULL
  *
  * Returns true on rule match, false on failure.
  */
 static bool ima_match_rules(struct ima_rule_entry *rule, struct inode *inode,
 			    const struct cred *cred, u32 secid,
 			    enum ima_hooks func, int mask,
-			    const char *keyring)
+			    const char *func_data)
 {
 	int i;
 
 	if (func == KEY_CHECK) {
 		return (rule->flags & IMA_FUNC) && (rule->func == func) &&
-		       ima_match_keyring(rule, keyring, cred);
+			ima_match_rule_data(rule, func_data, cred);
 	}
 	if ((rule->flags & IMA_FUNC) &&
 	    (rule->func != func && func != POST_SETATTR))
@@ -610,8 +620,7 @@ static int get_subaction(struct ima_rule_entry *rule, enum ima_hooks func)
  * @mask: requested action (MAY_READ | MAY_WRITE | MAY_APPEND | MAY_EXEC)
  * @pcr: set the pcr to extend
  * @template_desc: the template that should be used for this rule
- * @keyring: the keyring name, if given, to be used to check in the policy.
- *           keyring can be NULL if func is anything other than KEY_CHECK.
+ * @func_data: func specific data, may be NULL
  *
  * Measure decision based on func/mask/fsmagic and LSM(subj/obj/type)
  * conditions.
@@ -623,7 +632,7 @@ static int get_subaction(struct ima_rule_entry *rule, enum ima_hooks func)
 int ima_match_policy(struct inode *inode, const struct cred *cred, u32 secid,
 		     enum ima_hooks func, int mask, int flags, int *pcr,
 		     struct ima_template_desc **template_desc,
-		     const char *keyring)
+		     const char *func_data)
 {
 	struct ima_rule_entry *entry;
 	int action = 0, actmask = flags | (flags << 1);
@@ -638,7 +647,7 @@ int ima_match_policy(struct inode *inode, const struct cred *cred, u32 secid,
 			continue;
 
 		if (!ima_match_rules(entry, inode, cred, secid, func, mask,
-				     keyring))
+				     func_data))
 			continue;
 
 		action |= entry->flags & IMA_ACTION_FLAGS;
-- 
2.17.1


^ permalink raw reply related	[flat|nested] 28+ messages in thread

* [PATCH v10 2/8] IMA: add support to measure buffer data hash
  2021-01-08  4:07 [PATCH v10 0/8] IMA: support for measuring kernel integrity critical data Tushar Sugandhi
  2021-01-08  4:07 ` [PATCH v10 1/8] IMA: generalize keyring specific measurement constructs Tushar Sugandhi
@ 2021-01-08  4:07 ` Tushar Sugandhi
  2021-01-08  4:07 ` [PATCH v10 3/8] IMA: define a hook to measure kernel integrity critical data Tushar Sugandhi
                   ` (6 subsequent siblings)
  8 siblings, 0 replies; 28+ messages in thread
From: Tushar Sugandhi @ 2021-01-08  4:07 UTC (permalink / raw)
  To: zohar, stephen.smalley.work, casey, agk, snitzer, gmazyland, paul
  Cc: tyhicks, sashal, jmorris, nramas, linux-integrity, selinux,
	linux-security-module, linux-kernel, dm-devel

The original IMA buffer data measurement sizes were small (e.g.  boot
command line), but the new buffer data measurement use cases have data 
sizes that are a lot larger.  Just as IMA measures the file data hash,
not the file data, IMA should similarly support the option for measuring 
buffer data hash.

Introduce a boolean parameter to support measuring buffer data hash,
which would be much smaller, instead of the buffer itself.

Signed-off-by: Tushar Sugandhi <tusharsu@linux.microsoft.com>
Reviewed-by: Tyler Hicks <tyhicks@linux.microsoft.com>
---
 security/integrity/ima/ima.h                 |  3 +-
 security/integrity/ima/ima_appraise.c        |  2 +-
 security/integrity/ima/ima_asymmetric_keys.c |  2 +-
 security/integrity/ima/ima_main.c            | 29 ++++++++++++++++----
 security/integrity/ima/ima_queue_keys.c      |  3 +-
 5 files changed, 30 insertions(+), 9 deletions(-)

diff --git a/security/integrity/ima/ima.h b/security/integrity/ima/ima.h
index e5622ce8cbb1..0b4634515839 100644
--- a/security/integrity/ima/ima.h
+++ b/security/integrity/ima/ima.h
@@ -268,7 +268,8 @@ void ima_store_measurement(struct integrity_iint_cache *iint, struct file *file,
 			   struct ima_template_desc *template_desc);
 void process_buffer_measurement(struct inode *inode, const void *buf, int size,
 				const char *eventname, enum ima_hooks func,
-				int pcr, const char *func_data);
+				int pcr, const char *func_data,
+				bool buf_hash);
 void ima_audit_measurement(struct integrity_iint_cache *iint,
 			   const unsigned char *filename);
 int ima_alloc_init_template(struct ima_event_data *event_data,
diff --git a/security/integrity/ima/ima_appraise.c b/security/integrity/ima/ima_appraise.c
index 8361941ee0a1..46ffa38bab12 100644
--- a/security/integrity/ima/ima_appraise.c
+++ b/security/integrity/ima/ima_appraise.c
@@ -352,7 +352,7 @@ int ima_check_blacklist(struct integrity_iint_cache *iint,
 		if ((rc == -EPERM) && (iint->flags & IMA_MEASURE))
 			process_buffer_measurement(NULL, digest, digestsize,
 						   "blacklisted-hash", NONE,
-						   pcr, NULL);
+						   pcr, NULL, false);
 	}
 
 	return rc;
diff --git a/security/integrity/ima/ima_asymmetric_keys.c b/security/integrity/ima/ima_asymmetric_keys.c
index 1c68c500c26f..a74095793936 100644
--- a/security/integrity/ima/ima_asymmetric_keys.c
+++ b/security/integrity/ima/ima_asymmetric_keys.c
@@ -60,5 +60,5 @@ void ima_post_key_create_or_update(struct key *keyring, struct key *key,
 	 */
 	process_buffer_measurement(NULL, payload, payload_len,
 				   keyring->description, KEY_CHECK, 0,
-				   keyring->description);
+				   keyring->description, false);
 }
diff --git a/security/integrity/ima/ima_main.c b/security/integrity/ima/ima_main.c
index b4ed611cd2a4..494fb964497d 100644
--- a/security/integrity/ima/ima_main.c
+++ b/security/integrity/ima/ima_main.c
@@ -779,7 +779,7 @@ int ima_post_load_data(char *buf, loff_t size,
 }
 
 /*
- * process_buffer_measurement - Measure the buffer to ima log.
+ * process_buffer_measurement - Measure the buffer or the buffer data hash
  * @inode: inode associated with the object being measured (NULL for KEY_CHECK)
  * @buf: pointer to the buffer that needs to be added to the log.
  * @size: size of buffer(in bytes).
@@ -787,12 +787,14 @@ int ima_post_load_data(char *buf, loff_t size,
  * @func: IMA hook
  * @pcr: pcr to extend the measurement
  * @func_data: func specific data, may be NULL
+ * @buf_hash: measure buffer data hash
  *
- * Based on policy, the buffer is measured into the ima log.
+ * Based on policy, either the buffer data or buffer data hash is measured
  */
 void process_buffer_measurement(struct inode *inode, const void *buf, int size,
 				const char *eventname, enum ima_hooks func,
-				int pcr, const char *func_data)
+				int pcr, const char *func_data,
+				bool buf_hash)
 {
 	int ret = 0;
 	const char *audit_cause = "ENOMEM";
@@ -807,6 +809,8 @@ void process_buffer_measurement(struct inode *inode, const void *buf, int size,
 		struct ima_digest_data hdr;
 		char digest[IMA_MAX_DIGEST_SIZE];
 	} hash = {};
+	char digest_hash[IMA_MAX_DIGEST_SIZE];
+	int digest_hash_len = hash_digest_size[ima_hash_algo];
 	int violation = 0;
 	int action = 0;
 	u32 secid;
@@ -849,13 +853,27 @@ void process_buffer_measurement(struct inode *inode, const void *buf, int size,
 		goto out;
 	}
 
+	if (buf_hash) {
+		memcpy(digest_hash, hash.hdr.digest, digest_hash_len);
+
+		ret = ima_calc_buffer_hash(digest_hash, digest_hash_len,
+					   iint.ima_hash);
+		if (ret < 0) {
+			audit_cause = "hashing_error";
+			goto out;
+		}
+
+		event_data.buf = digest_hash;
+		event_data.buf_len = digest_hash_len;
+	}
+
 	ret = ima_alloc_init_template(&event_data, &entry, template);
 	if (ret < 0) {
 		audit_cause = "alloc_entry";
 		goto out;
 	}
 
-	ret = ima_store_template(entry, violation, NULL, buf, pcr);
+	ret = ima_store_template(entry, violation, NULL, event_data.buf, pcr);
 	if (ret < 0) {
 		audit_cause = "store_entry";
 		ima_free_template_entry(entry);
@@ -890,7 +908,8 @@ void ima_kexec_cmdline(int kernel_fd, const void *buf, int size)
 		return;
 
 	process_buffer_measurement(file_inode(f.file), buf, size,
-				   "kexec-cmdline", KEXEC_CMDLINE, 0, NULL);
+				   "kexec-cmdline", KEXEC_CMDLINE, 0, NULL,
+				   false);
 	fdput(f);
 }
 
diff --git a/security/integrity/ima/ima_queue_keys.c b/security/integrity/ima/ima_queue_keys.c
index 69a8626a35c0..c2f2ad34f9b7 100644
--- a/security/integrity/ima/ima_queue_keys.c
+++ b/security/integrity/ima/ima_queue_keys.c
@@ -162,7 +162,8 @@ void ima_process_queued_keys(void)
 						   entry->payload_len,
 						   entry->keyring_name,
 						   KEY_CHECK, 0,
-						   entry->keyring_name);
+						   entry->keyring_name,
+						   false);
 		list_del(&entry->list);
 		ima_free_key_entry(entry);
 	}
-- 
2.17.1


^ permalink raw reply related	[flat|nested] 28+ messages in thread

* [PATCH v10 3/8] IMA: define a hook to measure kernel integrity critical data
  2021-01-08  4:07 [PATCH v10 0/8] IMA: support for measuring kernel integrity critical data Tushar Sugandhi
  2021-01-08  4:07 ` [PATCH v10 1/8] IMA: generalize keyring specific measurement constructs Tushar Sugandhi
  2021-01-08  4:07 ` [PATCH v10 2/8] IMA: add support to measure buffer data hash Tushar Sugandhi
@ 2021-01-08  4:07 ` Tushar Sugandhi
  2021-01-08  4:07 ` [PATCH v10 4/8] IMA: add policy rule to measure " Tushar Sugandhi
                   ` (5 subsequent siblings)
  8 siblings, 0 replies; 28+ messages in thread
From: Tushar Sugandhi @ 2021-01-08  4:07 UTC (permalink / raw)
  To: zohar, stephen.smalley.work, casey, agk, snitzer, gmazyland, paul
  Cc: tyhicks, sashal, jmorris, nramas, linux-integrity, selinux,
	linux-security-module, linux-kernel, dm-devel

IMA provides capabilities to measure file and buffer data.  However,
various data structures, policies, and states stored in kernel memory
also impact the integrity of the system.  Several kernel subsystems
contain such integrity critical data.  These kernel subsystems help
protect the integrity of the system.  Currently, IMA does not provide a
generic function for measuring kernel integrity critical data.
 
Define ima_measure_critical_data, a new IMA hook, to measure kernel
integrity critical data.

Signed-off-by: Tushar Sugandhi <tusharsu@linux.microsoft.com>
Reviewed-by: Tyler Hicks <tyhicks@linux.microsoft.com>
---
 include/linux/ima.h               |  7 +++++++
 security/integrity/ima/ima.h      |  1 +
 security/integrity/ima/ima_api.c  |  2 +-
 security/integrity/ima/ima_main.c | 24 ++++++++++++++++++++++++
 4 files changed, 33 insertions(+), 1 deletion(-)

diff --git a/include/linux/ima.h b/include/linux/ima.h
index ac3d82f962f2..37a0727c1c31 100644
--- a/include/linux/ima.h
+++ b/include/linux/ima.h
@@ -30,6 +30,9 @@ extern int ima_post_read_file(struct file *file, void *buf, loff_t size,
 extern void ima_post_path_mknod(struct dentry *dentry);
 extern int ima_file_hash(struct file *file, char *buf, size_t buf_size);
 extern void ima_kexec_cmdline(int kernel_fd, const void *buf, int size);
+extern void ima_measure_critical_data(const char *event_name,
+				      const void *buf, size_t buf_len,
+				      bool hash);
 
 #ifdef CONFIG_IMA_APPRAISE_BOOTPARAM
 extern void ima_appraise_parse_cmdline(void);
@@ -122,6 +125,10 @@ static inline int ima_file_hash(struct file *file, char *buf, size_t buf_size)
 }
 
 static inline void ima_kexec_cmdline(int kernel_fd, const void *buf, int size) {}
+
+static inline void ima_measure_critical_data(const char *event_name,
+					     const void *buf, size_t buf_len,
+					     bool hash) {}
 #endif /* CONFIG_IMA */
 
 #ifndef CONFIG_IMA_KEXEC
diff --git a/security/integrity/ima/ima.h b/security/integrity/ima/ima.h
index 0b4634515839..aa312472c7c5 100644
--- a/security/integrity/ima/ima.h
+++ b/security/integrity/ima/ima.h
@@ -201,6 +201,7 @@ static inline unsigned int ima_hash_key(u8 *digest)
 	hook(POLICY_CHECK, policy)			\
 	hook(KEXEC_CMDLINE, kexec_cmdline)		\
 	hook(KEY_CHECK, key)				\
+	hook(CRITICAL_DATA, critical_data)		\
 	hook(MAX_CHECK, none)
 
 #define __ima_hook_enumify(ENUM, str)	ENUM,
diff --git a/security/integrity/ima/ima_api.c b/security/integrity/ima/ima_api.c
index e76499b1ce78..1dd70dc68ffd 100644
--- a/security/integrity/ima/ima_api.c
+++ b/security/integrity/ima/ima_api.c
@@ -176,7 +176,7 @@ void ima_add_violation(struct file *file, const unsigned char *filename,
  *		subj=, obj=, type=, func=, mask=, fsmagic=
  *	subj,obj, and type: are LSM specific.
  *	func: FILE_CHECK | BPRM_CHECK | CREDS_CHECK | MMAP_CHECK | MODULE_CHECK
- *	| KEXEC_CMDLINE | KEY_CHECK
+ *	| KEXEC_CMDLINE | KEY_CHECK | CRITICAL_DATA
  *	mask: contains the permission mask
  *	fsmagic: hex value
  *
diff --git a/security/integrity/ima/ima_main.c b/security/integrity/ima/ima_main.c
index 494fb964497d..ef37307e79dd 100644
--- a/security/integrity/ima/ima_main.c
+++ b/security/integrity/ima/ima_main.c
@@ -913,6 +913,30 @@ void ima_kexec_cmdline(int kernel_fd, const void *buf, int size)
 	fdput(f);
 }
 
+/**
+ * ima_measure_critical_data - measure kernel integrity critical data
+ * @event_name: event name for the record in the IMA measurement list
+ * @buf: pointer to buffer data
+ * @buf_len: length of buffer data (in bytes)
+ * @hash: measure buffer data hash
+ *
+ * Measure data critical to the integrity of the kernel into the IMA log
+ * and extend the pcr.  Examples of critical data could be various data
+ * structures, policies, and states stored in kernel memory that can
+ * impact the integrity of the system.
+ */
+void ima_measure_critical_data(const char *event_name,
+			       const void *buf, size_t buf_len,
+			       bool hash)
+{
+	if (!event_name || !buf || !buf_len)
+		return;
+
+	process_buffer_measurement(NULL, buf, buf_len, event_name,
+				   CRITICAL_DATA, 0, NULL,
+				   hash);
+}
+
 static int __init init_ima(void)
 {
 	int error;
-- 
2.17.1


^ permalink raw reply related	[flat|nested] 28+ messages in thread

* [PATCH v10 4/8] IMA: add policy rule to measure critical data
  2021-01-08  4:07 [PATCH v10 0/8] IMA: support for measuring kernel integrity critical data Tushar Sugandhi
                   ` (2 preceding siblings ...)
  2021-01-08  4:07 ` [PATCH v10 3/8] IMA: define a hook to measure kernel integrity critical data Tushar Sugandhi
@ 2021-01-08  4:07 ` Tushar Sugandhi
  2021-01-08  4:07 ` [PATCH v10 5/8] IMA: limit critical data measurement based on a label Tushar Sugandhi
                   ` (4 subsequent siblings)
  8 siblings, 0 replies; 28+ messages in thread
From: Tushar Sugandhi @ 2021-01-08  4:07 UTC (permalink / raw)
  To: zohar, stephen.smalley.work, casey, agk, snitzer, gmazyland, paul
  Cc: tyhicks, sashal, jmorris, nramas, linux-integrity, selinux,
	linux-security-module, linux-kernel, dm-devel

A new IMA policy rule is needed for the IMA hook
ima_measure_critical_data() and the corresponding func CRITICAL_DATA for
measuring the input buffer.  The policy rule should ensure the buffer
would get measured only when the policy rule allows the action.  The
policy rule should also support the necessary constraints (flags etc.)
for integrity critical buffer data measurements.

Add policy rule support for measuring integrity critical data.

Signed-off-by: Tushar Sugandhi <tusharsu@linux.microsoft.com>
Reviewed-by: Tyler Hicks <tyhicks@linux.microsoft.com>
Reviewed-by: Mimi Zohar <zohar@linux.ibm.com>
---
 Documentation/ABI/testing/ima_policy |  2 +-
 security/integrity/ima/ima_policy.c  | 29 ++++++++++++++++++++++++----
 2 files changed, 26 insertions(+), 5 deletions(-)

diff --git a/Documentation/ABI/testing/ima_policy b/Documentation/ABI/testing/ima_policy
index e35263f97fc1..6ec7daa87cba 100644
--- a/Documentation/ABI/testing/ima_policy
+++ b/Documentation/ABI/testing/ima_policy
@@ -32,7 +32,7 @@ Description:
 			func:= [BPRM_CHECK][MMAP_CHECK][CREDS_CHECK][FILE_CHECK]MODULE_CHECK]
 			        [FIRMWARE_CHECK]
 				[KEXEC_KERNEL_CHECK] [KEXEC_INITRAMFS_CHECK]
-				[KEXEC_CMDLINE] [KEY_CHECK]
+				[KEXEC_CMDLINE] [KEY_CHECK] [CRITICAL_DATA]
 			mask:= [[^]MAY_READ] [[^]MAY_WRITE] [[^]MAY_APPEND]
 			       [[^]MAY_EXEC]
 			fsmagic:= hex value
diff --git a/security/integrity/ima/ima_policy.c b/security/integrity/ima/ima_policy.c
index b93966034368..96ba4273c4d0 100644
--- a/security/integrity/ima/ima_policy.c
+++ b/security/integrity/ima/ima_policy.c
@@ -478,6 +478,8 @@ static bool ima_match_rule_data(struct ima_rule_entry *rule,
 
 		opt_list = rule->keyrings;
 		break;
+	case CRITICAL_DATA:
+		return true;
 	default:
 		return false;
 	}
@@ -514,13 +516,19 @@ static bool ima_match_rules(struct ima_rule_entry *rule, struct inode *inode,
 {
 	int i;
 
-	if (func == KEY_CHECK) {
-		return (rule->flags & IMA_FUNC) && (rule->func == func) &&
-			ima_match_rule_data(rule, func_data, cred);
-	}
 	if ((rule->flags & IMA_FUNC) &&
 	    (rule->func != func && func != POST_SETATTR))
 		return false;
+
+	switch (func) {
+	case KEY_CHECK:
+	case CRITICAL_DATA:
+		return ((rule->func == func) &&
+			ima_match_rule_data(rule, func_data, cred));
+	default:
+		break;
+	}
+
 	if ((rule->flags & IMA_MASK) &&
 	    (rule->mask != mask && func != POST_SETATTR))
 		return false;
@@ -1115,6 +1123,17 @@ static bool ima_validate_rule(struct ima_rule_entry *entry)
 		if (ima_rule_contains_lsm_cond(entry))
 			return false;
 
+		break;
+	case CRITICAL_DATA:
+		if (entry->action & ~(MEASURE | DONT_MEASURE))
+			return false;
+
+		if (entry->flags & ~(IMA_FUNC | IMA_UID | IMA_PCR))
+			return false;
+
+		if (ima_rule_contains_lsm_cond(entry))
+			return false;
+
 		break;
 	default:
 		return false;
@@ -1247,6 +1266,8 @@ static int ima_parse_rule(char *rule, struct ima_rule_entry *entry)
 			else if (IS_ENABLED(CONFIG_IMA_MEASURE_ASYMMETRIC_KEYS) &&
 				 strcmp(args[0].from, "KEY_CHECK") == 0)
 				entry->func = KEY_CHECK;
+			else if (strcmp(args[0].from, "CRITICAL_DATA") == 0)
+				entry->func = CRITICAL_DATA;
 			else
 				result = -EINVAL;
 			if (!result)
-- 
2.17.1


^ permalink raw reply related	[flat|nested] 28+ messages in thread

* [PATCH v10 5/8] IMA: limit critical data measurement based on a label
  2021-01-08  4:07 [PATCH v10 0/8] IMA: support for measuring kernel integrity critical data Tushar Sugandhi
                   ` (3 preceding siblings ...)
  2021-01-08  4:07 ` [PATCH v10 4/8] IMA: add policy rule to measure " Tushar Sugandhi
@ 2021-01-08  4:07 ` Tushar Sugandhi
  2021-01-14  2:09   ` Mimi Zohar
  2021-01-08  4:07 ` [PATCH v10 6/8] IMA: extend critical data hook to limit the " Tushar Sugandhi
                   ` (3 subsequent siblings)
  8 siblings, 1 reply; 28+ messages in thread
From: Tushar Sugandhi @ 2021-01-08  4:07 UTC (permalink / raw)
  To: zohar, stephen.smalley.work, casey, agk, snitzer, gmazyland, paul
  Cc: tyhicks, sashal, jmorris, nramas, linux-integrity, selinux,
	linux-security-module, linux-kernel, dm-devel

Integrity critical data may belong to a single subsystem or it may
arise from cross subsystem interaction.  Currently there is no mechanism
to group or limit the data based on certain label.  Limiting and
grouping critical data based on a label would make it flexible and
configurable to measure.

Define "label:=", a new IMA policy condition, for the IMA func
CRITICAL_DATA to allow grouping and limiting measurement of integrity
critical data.

Limit the measurement to the labels that are specified in the IMA
policy - CRITICAL_DATA+"label:=".  If "label:=" is not provided with
the func CRITICAL_DATA, measure all the input integrity critical data.

Signed-off-by: Tushar Sugandhi <tusharsu@linux.microsoft.com>
Reviewed-by: Tyler Hicks <tyhicks@linux.microsoft.com>
---
 Documentation/ABI/testing/ima_policy |  2 ++
 security/integrity/ima/ima_policy.c  | 37 +++++++++++++++++++++++++---
 2 files changed, 36 insertions(+), 3 deletions(-)

diff --git a/Documentation/ABI/testing/ima_policy b/Documentation/ABI/testing/ima_policy
index 6ec7daa87cba..54fe1c15ed50 100644
--- a/Documentation/ABI/testing/ima_policy
+++ b/Documentation/ABI/testing/ima_policy
@@ -52,6 +52,8 @@ Description:
 			template:= name of a defined IMA template type
 			(eg, ima-ng). Only valid when action is "measure".
 			pcr:= decimal value
+			label:= [data_label]
+			data_label:= a unique string used for grouping and limiting critical data.
 
 		  default policy:
 			# PROC_SUPER_MAGIC
diff --git a/security/integrity/ima/ima_policy.c b/security/integrity/ima/ima_policy.c
index 96ba4273c4d0..2c9db2d0b434 100644
--- a/security/integrity/ima/ima_policy.c
+++ b/security/integrity/ima/ima_policy.c
@@ -34,6 +34,7 @@
 #define IMA_PCR		0x0100
 #define IMA_FSNAME	0x0200
 #define IMA_KEYRINGS	0x0400
+#define IMA_LABEL	0x0800
 
 #define UNKNOWN		0
 #define MEASURE		0x0001	/* same as IMA_MEASURE */
@@ -85,6 +86,7 @@ struct ima_rule_entry {
 	} lsm[MAX_LSM_RULES];
 	char *fsname;
 	struct ima_rule_opt_list *keyrings; /* Measure keys added to these keyrings */
+	struct ima_rule_opt_list *label; /* Measure data grouped under this label */
 	struct ima_template_desc *template;
 };
 
@@ -479,7 +481,11 @@ static bool ima_match_rule_data(struct ima_rule_entry *rule,
 		opt_list = rule->keyrings;
 		break;
 	case CRITICAL_DATA:
-		return true;
+		if (!rule->label)
+			return true;
+
+		opt_list = rule->label;
+		break;
 	default:
 		return false;
 	}
@@ -924,7 +930,7 @@ enum {
 	Opt_uid_lt, Opt_euid_lt, Opt_fowner_lt,
 	Opt_appraise_type, Opt_appraise_flag,
 	Opt_permit_directio, Opt_pcr, Opt_template, Opt_keyrings,
-	Opt_err
+	Opt_label, Opt_err
 };
 
 static const match_table_t policy_tokens = {
@@ -961,6 +967,7 @@ static const match_table_t policy_tokens = {
 	{Opt_pcr, "pcr=%s"},
 	{Opt_template, "template=%s"},
 	{Opt_keyrings, "keyrings=%s"},
+	{Opt_label, "label=%s"},
 	{Opt_err, NULL}
 };
 
@@ -1128,7 +1135,8 @@ static bool ima_validate_rule(struct ima_rule_entry *entry)
 		if (entry->action & ~(MEASURE | DONT_MEASURE))
 			return false;
 
-		if (entry->flags & ~(IMA_FUNC | IMA_UID | IMA_PCR))
+		if (entry->flags & ~(IMA_FUNC | IMA_UID | IMA_PCR |
+				     IMA_LABEL))
 			return false;
 
 		if (ima_rule_contains_lsm_cond(entry))
@@ -1338,6 +1346,23 @@ static int ima_parse_rule(char *rule, struct ima_rule_entry *entry)
 
 			entry->flags |= IMA_KEYRINGS;
 			break;
+		case Opt_label:
+			ima_log_string(ab, "label", args[0].from);
+
+			if (entry->label) {
+				result = -EINVAL;
+				break;
+			}
+
+			entry->label = ima_alloc_rule_opt_list(args);
+			if (IS_ERR(entry->label)) {
+				result = PTR_ERR(entry->label);
+				entry->label = NULL;
+				break;
+			}
+
+			entry->flags |= IMA_LABEL;
+			break;
 		case Opt_fsuuid:
 			ima_log_string(ab, "fsuuid", args[0].from);
 
@@ -1718,6 +1743,12 @@ int ima_policy_show(struct seq_file *m, void *v)
 		seq_puts(m, " ");
 	}
 
+	if (entry->flags & IMA_LABEL) {
+		seq_puts(m, "label=");
+		ima_show_rule_opt_list(m, entry->label);
+		seq_puts(m, " ");
+	}
+
 	if (entry->flags & IMA_PCR) {
 		snprintf(tbuf, sizeof(tbuf), "%d", entry->pcr);
 		seq_printf(m, pt(Opt_pcr), tbuf);
-- 
2.17.1


^ permalink raw reply related	[flat|nested] 28+ messages in thread

* [PATCH v10 6/8] IMA: extend critical data hook to limit the measurement based on a label
  2021-01-08  4:07 [PATCH v10 0/8] IMA: support for measuring kernel integrity critical data Tushar Sugandhi
                   ` (4 preceding siblings ...)
  2021-01-08  4:07 ` [PATCH v10 5/8] IMA: limit critical data measurement based on a label Tushar Sugandhi
@ 2021-01-08  4:07 ` Tushar Sugandhi
  2021-01-08  4:07 ` [PATCH v10 7/8] IMA: define a builtin critical data measurement policy Tushar Sugandhi
                   ` (2 subsequent siblings)
  8 siblings, 0 replies; 28+ messages in thread
From: Tushar Sugandhi @ 2021-01-08  4:07 UTC (permalink / raw)
  To: zohar, stephen.smalley.work, casey, agk, snitzer, gmazyland, paul
  Cc: tyhicks, sashal, jmorris, nramas, linux-integrity, selinux,
	linux-security-module, linux-kernel, dm-devel

The IMA hook ima_measure_critical_data() does not support a way to
specify the source of the critical data provider.  Thus, the data
measurement cannot be constrained based on the data source label
in the IMA policy.

Extend the IMA hook ima_measure_critical_data() to support passing 
the data source label as an input parameter, so that the policy rule can
be used to limit the measurements based on the label.

Signed-off-by: Tushar Sugandhi <tusharsu@linux.microsoft.com>
Reviewed-by: Tyler Hicks <tyhicks@linux.microsoft.com>
---
 include/linux/ima.h               | 7 +++++--
 security/integrity/ima/ima_main.c | 8 +++++---
 2 files changed, 10 insertions(+), 5 deletions(-)

diff --git a/include/linux/ima.h b/include/linux/ima.h
index 37a0727c1c31..6d00542de135 100644
--- a/include/linux/ima.h
+++ b/include/linux/ima.h
@@ -30,7 +30,8 @@ extern int ima_post_read_file(struct file *file, void *buf, loff_t size,
 extern void ima_post_path_mknod(struct dentry *dentry);
 extern int ima_file_hash(struct file *file, char *buf, size_t buf_size);
 extern void ima_kexec_cmdline(int kernel_fd, const void *buf, int size);
-extern void ima_measure_critical_data(const char *event_name,
+extern void ima_measure_critical_data(const char *event_label,
+				      const char *event_name,
 				      const void *buf, size_t buf_len,
 				      bool hash);
 
@@ -126,9 +127,11 @@ static inline int ima_file_hash(struct file *file, char *buf, size_t buf_size)
 
 static inline void ima_kexec_cmdline(int kernel_fd, const void *buf, int size) {}
 
-static inline void ima_measure_critical_data(const char *event_name,
+static inline void ima_measure_critical_data(const char *event_label,
+					     const char *event_name,
 					     const void *buf, size_t buf_len,
 					     bool hash) {}
+
 #endif /* CONFIG_IMA */
 
 #ifndef CONFIG_IMA_KEXEC
diff --git a/security/integrity/ima/ima_main.c b/security/integrity/ima/ima_main.c
index ef37307e79dd..edfb1367a11d 100644
--- a/security/integrity/ima/ima_main.c
+++ b/security/integrity/ima/ima_main.c
@@ -915,6 +915,7 @@ void ima_kexec_cmdline(int kernel_fd, const void *buf, int size)
 
 /**
  * ima_measure_critical_data - measure kernel integrity critical data
+ * @event_label: unique event label for grouping and limiting critical data
  * @event_name: event name for the record in the IMA measurement list
  * @buf: pointer to buffer data
  * @buf_len: length of buffer data (in bytes)
@@ -925,15 +926,16 @@ void ima_kexec_cmdline(int kernel_fd, const void *buf, int size)
  * structures, policies, and states stored in kernel memory that can
  * impact the integrity of the system.
  */
-void ima_measure_critical_data(const char *event_name,
+void ima_measure_critical_data(const char *event_label,
+			       const char *event_name,
 			       const void *buf, size_t buf_len,
 			       bool hash)
 {
-	if (!event_name || !buf || !buf_len)
+	if (!event_name || !event_label || !buf || !buf_len)
 		return;
 
 	process_buffer_measurement(NULL, buf, buf_len, event_name,
-				   CRITICAL_DATA, 0, NULL,
+				   CRITICAL_DATA, 0, event_label,
 				   hash);
 }
 
-- 
2.17.1


^ permalink raw reply related	[flat|nested] 28+ messages in thread

* [PATCH v10 7/8] IMA: define a builtin critical data measurement policy
  2021-01-08  4:07 [PATCH v10 0/8] IMA: support for measuring kernel integrity critical data Tushar Sugandhi
                   ` (5 preceding siblings ...)
  2021-01-08  4:07 ` [PATCH v10 6/8] IMA: extend critical data hook to limit the " Tushar Sugandhi
@ 2021-01-08  4:07 ` Tushar Sugandhi
  2021-01-08  4:07 ` [PATCH v10 8/8] selinux: include a consumer of the new IMA critical data hook Tushar Sugandhi
  2021-01-15 12:54 ` [PATCH v10 0/8] IMA: support for measuring kernel integrity critical data Mimi Zohar
  8 siblings, 0 replies; 28+ messages in thread
From: Tushar Sugandhi @ 2021-01-08  4:07 UTC (permalink / raw)
  To: zohar, stephen.smalley.work, casey, agk, snitzer, gmazyland, paul
  Cc: tyhicks, sashal, jmorris, nramas, linux-integrity, selinux,
	linux-security-module, linux-kernel, dm-devel

From: Lakshmi Ramasubramanian <nramas@linux.microsoft.com>

Define a new critical data builtin policy to allow measuring
early kernel integrity critical data before a custom IMA policy
is loaded.

Update the documentation on kernel parameters to document
the new critical data builtin policy.

Signed-off-by: Lakshmi Ramasubramanian <nramas@linux.microsoft.com>
Reviewed-by: Tyler Hicks <tyhicks@linux.microsoft.com>
Reviewed-by: Mimi Zohar <zohar@linux.ibm.com>
---
 Documentation/admin-guide/kernel-parameters.txt |  5 ++++-
 security/integrity/ima/ima_policy.c             | 12 ++++++++++++
 2 files changed, 16 insertions(+), 1 deletion(-)

diff --git a/Documentation/admin-guide/kernel-parameters.txt b/Documentation/admin-guide/kernel-parameters.txt
index 526d65d8573a..6034d75c3ca0 100644
--- a/Documentation/admin-guide/kernel-parameters.txt
+++ b/Documentation/admin-guide/kernel-parameters.txt
@@ -1746,7 +1746,7 @@
 	ima_policy=	[IMA]
 			The builtin policies to load during IMA setup.
 			Format: "tcb | appraise_tcb | secure_boot |
-				 fail_securely"
+				 fail_securely | critical_data"
 
 			The "tcb" policy measures all programs exec'd, files
 			mmap'd for exec, and all files opened with the read
@@ -1765,6 +1765,9 @@
 			filesystems with the SB_I_UNVERIFIABLE_SIGNATURE
 			flag.
 
+			The "critical_data" policy measures kernel integrity
+			critical data.
+
 	ima_tcb		[IMA] Deprecated.  Use ima_policy= instead.
 			Load a policy which meets the needs of the Trusted
 			Computing Base.  This means IMA will measure all
diff --git a/security/integrity/ima/ima_policy.c b/security/integrity/ima/ima_policy.c
index 2c9db2d0b434..9b45d064a87d 100644
--- a/security/integrity/ima/ima_policy.c
+++ b/security/integrity/ima/ima_policy.c
@@ -206,6 +206,10 @@ static struct ima_rule_entry secure_boot_rules[] __ro_after_init = {
 	 .flags = IMA_FUNC | IMA_DIGSIG_REQUIRED},
 };
 
+static struct ima_rule_entry critical_data_rules[] __ro_after_init = {
+	{.action = MEASURE, .func = CRITICAL_DATA, .flags = IMA_FUNC},
+};
+
 /* An array of architecture specific rules */
 static struct ima_rule_entry *arch_policy_entry __ro_after_init;
 
@@ -228,6 +232,7 @@ __setup("ima_tcb", default_measure_policy_setup);
 
 static bool ima_use_appraise_tcb __initdata;
 static bool ima_use_secure_boot __initdata;
+static bool ima_use_critical_data __initdata;
 static bool ima_fail_unverifiable_sigs __ro_after_init;
 static int __init policy_setup(char *str)
 {
@@ -242,6 +247,8 @@ static int __init policy_setup(char *str)
 			ima_use_appraise_tcb = true;
 		else if (strcmp(p, "secure_boot") == 0)
 			ima_use_secure_boot = true;
+		else if (strcmp(p, "critical_data") == 0)
+			ima_use_critical_data = true;
 		else if (strcmp(p, "fail_securely") == 0)
 			ima_fail_unverifiable_sigs = true;
 		else
@@ -871,6 +878,11 @@ void __init ima_init_policy(void)
 			  ARRAY_SIZE(default_appraise_rules),
 			  IMA_DEFAULT_POLICY);
 
+	if (ima_use_critical_data)
+		add_rules(critical_data_rules,
+			  ARRAY_SIZE(critical_data_rules),
+			  IMA_DEFAULT_POLICY);
+
 	ima_update_policy_flag();
 }
 
-- 
2.17.1


^ permalink raw reply related	[flat|nested] 28+ messages in thread

* [PATCH v10 8/8] selinux: include a consumer of the new IMA critical data hook
  2021-01-08  4:07 [PATCH v10 0/8] IMA: support for measuring kernel integrity critical data Tushar Sugandhi
                   ` (6 preceding siblings ...)
  2021-01-08  4:07 ` [PATCH v10 7/8] IMA: define a builtin critical data measurement policy Tushar Sugandhi
@ 2021-01-08  4:07 ` Tushar Sugandhi
  2021-01-12 16:27   ` Paul Moore
  2021-01-15 12:54 ` [PATCH v10 0/8] IMA: support for measuring kernel integrity critical data Mimi Zohar
  8 siblings, 1 reply; 28+ messages in thread
From: Tushar Sugandhi @ 2021-01-08  4:07 UTC (permalink / raw)
  To: zohar, stephen.smalley.work, casey, agk, snitzer, gmazyland, paul
  Cc: tyhicks, sashal, jmorris, nramas, linux-integrity, selinux,
	linux-security-module, linux-kernel, dm-devel

From: Lakshmi Ramasubramanian <nramas@linux.microsoft.com>

SELinux stores the active policy in memory, so the changes to this data
at runtime would have an impact on the security guarantees provided
by SELinux.  Measuring in-memory SELinux policy through IMA subsystem
provides a secure way for the attestation service to remotely validate
the policy contents at runtime.

Measure the hash of the loaded policy by calling the IMA hook
ima_measure_critical_data().  Since the size of the loaded policy
can be large (several MB), measure the hash of the policy instead of
the entire policy to avoid bloating the IMA log entry.

To enable SELinux data measurement, the following steps are required:

1, Add "ima_policy=critical_data" to the kernel command line arguments
   to enable measuring SELinux data at boot time.
For example,
  BOOT_IMAGE=/boot/vmlinuz-5.10.0-rc1+ root=UUID=fd643309-a5d2-4ed3-b10d-3c579a5fab2f ro nomodeset security=selinux ima_policy=critical_data

2, Add the following rule to /etc/ima/ima-policy
   measure func=CRITICAL_DATA label=selinux

Sample measurement of the hash of SELinux policy:

To verify the measured data with the current SELinux policy run
the following commands and verify the output hash values match.

  sha256sum /sys/fs/selinux/policy | cut -d' ' -f 1

  grep "selinux-policy-hash" /sys/kernel/security/integrity/ima/ascii_runtime_measurements | tail -1 | cut -d' ' -f 6

Note that the actual verification of SELinux policy would require loading
the expected policy into an identical kernel on a pristine/known-safe
system and run the sha256sum /sys/kernel/selinux/policy there to get
the expected hash.

Signed-off-by: Lakshmi Ramasubramanian <nramas@linux.microsoft.com>
Suggested-by: Stephen Smalley <stephen.smalley.work@gmail.com>
Reviewed-by: Tyler Hicks <tyhicks@linux.microsoft.com>
---
 Documentation/ABI/testing/ima_policy |  3 +-
 security/selinux/Makefile            |  2 +
 security/selinux/ima.c               | 64 ++++++++++++++++++++++++++++
 security/selinux/include/ima.h       | 24 +++++++++++
 security/selinux/include/security.h  |  3 +-
 security/selinux/ss/services.c       | 64 ++++++++++++++++++++++++----
 6 files changed, 149 insertions(+), 11 deletions(-)
 create mode 100644 security/selinux/ima.c
 create mode 100644 security/selinux/include/ima.h

diff --git a/Documentation/ABI/testing/ima_policy b/Documentation/ABI/testing/ima_policy
index 54fe1c15ed50..8365596cb42b 100644
--- a/Documentation/ABI/testing/ima_policy
+++ b/Documentation/ABI/testing/ima_policy
@@ -52,8 +52,9 @@ Description:
 			template:= name of a defined IMA template type
 			(eg, ima-ng). Only valid when action is "measure".
 			pcr:= decimal value
-			label:= [data_label]
+			label:= [selinux]|[data_label]
 			data_label:= a unique string used for grouping and limiting critical data.
+			For example, "selinux" to measure critical data for SELinux.
 
 		  default policy:
 			# PROC_SUPER_MAGIC
diff --git a/security/selinux/Makefile b/security/selinux/Makefile
index 4d8e0e8adf0b..776162444882 100644
--- a/security/selinux/Makefile
+++ b/security/selinux/Makefile
@@ -16,6 +16,8 @@ selinux-$(CONFIG_NETLABEL) += netlabel.o
 
 selinux-$(CONFIG_SECURITY_INFINIBAND) += ibpkey.o
 
+selinux-$(CONFIG_IMA) += ima.o
+
 ccflags-y := -I$(srctree)/security/selinux -I$(srctree)/security/selinux/include
 
 $(addprefix $(obj)/,$(selinux-y)): $(obj)/flask.h
diff --git a/security/selinux/ima.c b/security/selinux/ima.c
new file mode 100644
index 000000000000..0b835bdc3aa9
--- /dev/null
+++ b/security/selinux/ima.c
@@ -0,0 +1,64 @@
+// SPDX-License-Identifier: GPL-2.0+
+/*
+ * Copyright (C) 2021 Microsoft Corporation
+ *
+ * Author: Lakshmi Ramasubramanian (nramas@linux.microsoft.com)
+ *
+ * Measure critical data structures maintainted by SELinux
+ * using IMA subsystem.
+ */
+#include <linux/vmalloc.h>
+#include <linux/ktime.h>
+#include <linux/ima.h>
+#include "security.h"
+#include "ima.h"
+
+/*
+ * selinux_ima_measure_state - Measure hash of the SELinux policy
+ *
+ * @state: selinux state struct
+ *
+ * NOTE: This function must be called with policy_mutex held.
+ */
+void selinux_ima_measure_state(struct selinux_state *state)
+{
+	struct timespec64 cur_time;
+	void *policy = NULL;
+	char *policy_event_name = NULL;
+	size_t policy_len;
+	int rc = 0;
+
+	/*
+	 * Measure SELinux policy only after initialization is completed.
+	 */
+	if (!selinux_initialized(state))
+		return;
+
+	/*
+	 * Pass a unique "event_name" to the IMA hook so that IMA subsystem
+	 * will always measure the given data.
+	 */
+	ktime_get_real_ts64(&cur_time);
+	policy_event_name = kasprintf(GFP_KERNEL, "%s-%lld:%09ld",
+				      "selinux-policy-hash",
+				      cur_time.tv_sec, cur_time.tv_nsec);
+	if (!policy_event_name) {
+		pr_err("SELinux: %s: event name for policy not allocated.\n",
+		       __func__);
+		goto out;
+	}
+
+	rc = security_read_state_kernel(state, &policy, &policy_len);
+	if (rc) {
+		pr_err("SELinux: %s: failed to read policy %d.\n", __func__, rc);
+		goto out;
+	}
+
+	ima_measure_critical_data("selinux", policy_event_name,
+				  policy, policy_len, true);
+
+	vfree(policy);
+
+out:
+	kfree(policy_event_name);
+}
diff --git a/security/selinux/include/ima.h b/security/selinux/include/ima.h
new file mode 100644
index 000000000000..d69c36611423
--- /dev/null
+++ b/security/selinux/include/ima.h
@@ -0,0 +1,24 @@
+/* SPDX-License-Identifier: GPL-2.0+ */
+/*
+ * Copyright (C) 2021 Microsoft Corporation
+ *
+ * Author: Lakshmi Ramasubramanian (nramas@linux.microsoft.com)
+ *
+ * Measure critical data structures maintainted by SELinux
+ * using IMA subsystem.
+ */
+
+#ifndef _SELINUX_IMA_H_
+#define _SELINUX_IMA_H_
+
+#include "security.h"
+
+#ifdef CONFIG_IMA
+extern void selinux_ima_measure_state(struct selinux_state *selinux_state);
+#else
+static inline void selinux_ima_measure_state(struct selinux_state *selinux_state)
+{
+}
+#endif
+
+#endif	/* _SELINUX_IMA_H_ */
diff --git a/security/selinux/include/security.h b/security/selinux/include/security.h
index 3cc8bab31ea8..29cae32d3fc5 100644
--- a/security/selinux/include/security.h
+++ b/security/selinux/include/security.h
@@ -229,7 +229,8 @@ void selinux_policy_cancel(struct selinux_state *state,
 			struct selinux_policy *policy);
 int security_read_policy(struct selinux_state *state,
 			 void **data, size_t *len);
-
+int security_read_state_kernel(struct selinux_state *state,
+			       void **data, size_t *len);
 int security_policycap_supported(struct selinux_state *state,
 				 unsigned int req_cap);
 
diff --git a/security/selinux/ss/services.c b/security/selinux/ss/services.c
index 9704c8a32303..cc8dbc4ed8db 100644
--- a/security/selinux/ss/services.c
+++ b/security/selinux/ss/services.c
@@ -65,6 +65,7 @@
 #include "ebitmap.h"
 #include "audit.h"
 #include "policycap_names.h"
+#include "ima.h"
 
 /* Forward declaration. */
 static int context_struct_to_string(struct policydb *policydb,
@@ -2180,6 +2181,7 @@ static void selinux_notify_policy_change(struct selinux_state *state,
 	selinux_status_update_policyload(state, seqno);
 	selinux_netlbl_cache_invalidate();
 	selinux_xfrm_notify_policyload();
+	selinux_ima_measure_state(state);
 }
 
 void selinux_policy_commit(struct selinux_state *state,
@@ -3875,8 +3877,33 @@ int security_netlbl_sid_to_secattr(struct selinux_state *state,
 }
 #endif /* CONFIG_NETLABEL */
 
+/**
+ * __security_read_policy - read the policy.
+ * @policy: SELinux policy
+ * @data: binary policy data
+ * @len: length of data in bytes
+ *
+ */
+static int __security_read_policy(struct selinux_policy *policy,
+				  void *data, size_t *len)
+{
+	int rc;
+	struct policy_file fp;
+
+	fp.data = data;
+	fp.len = *len;
+
+	rc = policydb_write(&policy->policydb, &fp);
+	if (rc)
+		return rc;
+
+	*len = (unsigned long)fp.data - (unsigned long)data;
+	return 0;
+}
+
 /**
  * security_read_policy - read the policy.
+ * @state: selinux_state
  * @data: binary policy data
  * @len: length of data in bytes
  *
@@ -3885,8 +3912,6 @@ int security_read_policy(struct selinux_state *state,
 			 void **data, size_t *len)
 {
 	struct selinux_policy *policy;
-	int rc;
-	struct policy_file fp;
 
 	policy = rcu_dereference_protected(
 			state->policy, lockdep_is_held(&state->policy_mutex));
@@ -3898,14 +3923,35 @@ int security_read_policy(struct selinux_state *state,
 	if (!*data)
 		return -ENOMEM;
 
-	fp.data = *data;
-	fp.len = *len;
+	return __security_read_policy(policy, *data, len);
+}
 
-	rc = policydb_write(&policy->policydb, &fp);
-	if (rc)
-		return rc;
+/**
+ * security_read_state_kernel - read the policy.
+ * @state: selinux_state
+ * @data: binary policy data
+ * @len: length of data in bytes
+ *
+ * Allocates kernel memory for reading SELinux policy.
+ * This function is for internal use only and should not
+ * be used for returning data to user space.
+ *
+ * This function must be called with policy_mutex held.
+ */
+int security_read_state_kernel(struct selinux_state *state,
+			       void **data, size_t *len)
+{
+	struct selinux_policy *policy;
 
-	*len = (unsigned long)fp.data - (unsigned long)*data;
-	return 0;
+	policy = rcu_dereference_protected(
+			state->policy, lockdep_is_held(&state->policy_mutex));
+	if (!policy)
+		return -EINVAL;
+
+	*len = policy->policydb.len;
+	*data = vmalloc(*len);
+	if (!*data)
+		return -ENOMEM;
 
+	return __security_read_policy(policy, *data, len);
 }
-- 
2.17.1


^ permalink raw reply related	[flat|nested] 28+ messages in thread

* Re: [PATCH v10 8/8] selinux: include a consumer of the new IMA critical data hook
  2021-01-08  4:07 ` [PATCH v10 8/8] selinux: include a consumer of the new IMA critical data hook Tushar Sugandhi
@ 2021-01-12 16:27   ` Paul Moore
  2021-01-12 18:25     ` Lakshmi Ramasubramanian
  2021-01-13 19:13     ` Mimi Zohar
  0 siblings, 2 replies; 28+ messages in thread
From: Paul Moore @ 2021-01-12 16:27 UTC (permalink / raw)
  To: Tushar Sugandhi
  Cc: zohar, Stephen Smalley, casey, agk, snitzer, gmazyland, tyhicks,
	sashal, James Morris, nramas, linux-integrity, selinux,
	linux-security-module, linux-kernel, dm-devel

On Thu, Jan 7, 2021 at 11:07 PM Tushar Sugandhi
<tusharsu@linux.microsoft.com> wrote:
> From: Lakshmi Ramasubramanian <nramas@linux.microsoft.com>
>
> SELinux stores the active policy in memory, so the changes to this data
> at runtime would have an impact on the security guarantees provided
> by SELinux.  Measuring in-memory SELinux policy through IMA subsystem
> provides a secure way for the attestation service to remotely validate
> the policy contents at runtime.
>
> Measure the hash of the loaded policy by calling the IMA hook
> ima_measure_critical_data().  Since the size of the loaded policy
> can be large (several MB), measure the hash of the policy instead of
> the entire policy to avoid bloating the IMA log entry.
>
> To enable SELinux data measurement, the following steps are required:
>
> 1, Add "ima_policy=critical_data" to the kernel command line arguments
>    to enable measuring SELinux data at boot time.
> For example,
>   BOOT_IMAGE=/boot/vmlinuz-5.10.0-rc1+ root=UUID=fd643309-a5d2-4ed3-b10d-3c579a5fab2f ro nomodeset security=selinux ima_policy=critical_data
>
> 2, Add the following rule to /etc/ima/ima-policy
>    measure func=CRITICAL_DATA label=selinux
>
> Sample measurement of the hash of SELinux policy:
>
> To verify the measured data with the current SELinux policy run
> the following commands and verify the output hash values match.
>
>   sha256sum /sys/fs/selinux/policy | cut -d' ' -f 1
>
>   grep "selinux-policy-hash" /sys/kernel/security/integrity/ima/ascii_runtime_measurements | tail -1 | cut -d' ' -f 6
>
> Note that the actual verification of SELinux policy would require loading
> the expected policy into an identical kernel on a pristine/known-safe
> system and run the sha256sum /sys/kernel/selinux/policy there to get
> the expected hash.
>
> Signed-off-by: Lakshmi Ramasubramanian <nramas@linux.microsoft.com>
> Suggested-by: Stephen Smalley <stephen.smalley.work@gmail.com>
> Reviewed-by: Tyler Hicks <tyhicks@linux.microsoft.com>
> ---
>  Documentation/ABI/testing/ima_policy |  3 +-
>  security/selinux/Makefile            |  2 +
>  security/selinux/ima.c               | 64 ++++++++++++++++++++++++++++
>  security/selinux/include/ima.h       | 24 +++++++++++
>  security/selinux/include/security.h  |  3 +-
>  security/selinux/ss/services.c       | 64 ++++++++++++++++++++++++----
>  6 files changed, 149 insertions(+), 11 deletions(-)
>  create mode 100644 security/selinux/ima.c
>  create mode 100644 security/selinux/include/ima.h

I remain concerned about the possibility of bypassing a measurement by
tampering with the time, but I appear to be the only one who is
worried about this so I'm not going to block this patch on those
grounds.

Acked-by: Paul Moore <paul@paul-moore.com>

> diff --git a/Documentation/ABI/testing/ima_policy b/Documentation/ABI/testing/ima_policy
> index 54fe1c15ed50..8365596cb42b 100644
> --- a/Documentation/ABI/testing/ima_policy
> +++ b/Documentation/ABI/testing/ima_policy
> @@ -52,8 +52,9 @@ Description:
>                         template:= name of a defined IMA template type
>                         (eg, ima-ng). Only valid when action is "measure".
>                         pcr:= decimal value
> -                       label:= [data_label]
> +                       label:= [selinux]|[data_label]
>                         data_label:= a unique string used for grouping and limiting critical data.
> +                       For example, "selinux" to measure critical data for SELinux.
>
>                   default policy:
>                         # PROC_SUPER_MAGIC
> diff --git a/security/selinux/Makefile b/security/selinux/Makefile
> index 4d8e0e8adf0b..776162444882 100644
> --- a/security/selinux/Makefile
> +++ b/security/selinux/Makefile
> @@ -16,6 +16,8 @@ selinux-$(CONFIG_NETLABEL) += netlabel.o
>
>  selinux-$(CONFIG_SECURITY_INFINIBAND) += ibpkey.o
>
> +selinux-$(CONFIG_IMA) += ima.o
> +
>  ccflags-y := -I$(srctree)/security/selinux -I$(srctree)/security/selinux/include
>
>  $(addprefix $(obj)/,$(selinux-y)): $(obj)/flask.h
> diff --git a/security/selinux/ima.c b/security/selinux/ima.c
> new file mode 100644
> index 000000000000..0b835bdc3aa9
> --- /dev/null
> +++ b/security/selinux/ima.c
> @@ -0,0 +1,64 @@
> +// SPDX-License-Identifier: GPL-2.0+
> +/*
> + * Copyright (C) 2021 Microsoft Corporation
> + *
> + * Author: Lakshmi Ramasubramanian (nramas@linux.microsoft.com)
> + *
> + * Measure critical data structures maintainted by SELinux
> + * using IMA subsystem.
> + */
> +#include <linux/vmalloc.h>
> +#include <linux/ktime.h>
> +#include <linux/ima.h>
> +#include "security.h"
> +#include "ima.h"
> +
> +/*
> + * selinux_ima_measure_state - Measure hash of the SELinux policy
> + *
> + * @state: selinux state struct
> + *
> + * NOTE: This function must be called with policy_mutex held.
> + */
> +void selinux_ima_measure_state(struct selinux_state *state)
> +{
> +       struct timespec64 cur_time;
> +       void *policy = NULL;
> +       char *policy_event_name = NULL;
> +       size_t policy_len;
> +       int rc = 0;
> +
> +       /*
> +        * Measure SELinux policy only after initialization is completed.
> +        */
> +       if (!selinux_initialized(state))
> +               return;
> +
> +       /*
> +        * Pass a unique "event_name" to the IMA hook so that IMA subsystem
> +        * will always measure the given data.
> +        */
> +       ktime_get_real_ts64(&cur_time);
> +       policy_event_name = kasprintf(GFP_KERNEL, "%s-%lld:%09ld",
> +                                     "selinux-policy-hash",
> +                                     cur_time.tv_sec, cur_time.tv_nsec);
> +       if (!policy_event_name) {
> +               pr_err("SELinux: %s: event name for policy not allocated.\n",
> +                      __func__);
> +               goto out;
> +       }
> +
> +       rc = security_read_state_kernel(state, &policy, &policy_len);
> +       if (rc) {
> +               pr_err("SELinux: %s: failed to read policy %d.\n", __func__, rc);
> +               goto out;
> +       }
> +
> +       ima_measure_critical_data("selinux", policy_event_name,
> +                                 policy, policy_len, true);
> +
> +       vfree(policy);
> +
> +out:
> +       kfree(policy_event_name);
> +}
> diff --git a/security/selinux/include/ima.h b/security/selinux/include/ima.h
> new file mode 100644
> index 000000000000..d69c36611423
> --- /dev/null
> +++ b/security/selinux/include/ima.h
> @@ -0,0 +1,24 @@
> +/* SPDX-License-Identifier: GPL-2.0+ */
> +/*
> + * Copyright (C) 2021 Microsoft Corporation
> + *
> + * Author: Lakshmi Ramasubramanian (nramas@linux.microsoft.com)
> + *
> + * Measure critical data structures maintainted by SELinux
> + * using IMA subsystem.
> + */
> +
> +#ifndef _SELINUX_IMA_H_
> +#define _SELINUX_IMA_H_
> +
> +#include "security.h"
> +
> +#ifdef CONFIG_IMA
> +extern void selinux_ima_measure_state(struct selinux_state *selinux_state);
> +#else
> +static inline void selinux_ima_measure_state(struct selinux_state *selinux_state)
> +{
> +}
> +#endif
> +
> +#endif /* _SELINUX_IMA_H_ */
> diff --git a/security/selinux/include/security.h b/security/selinux/include/security.h
> index 3cc8bab31ea8..29cae32d3fc5 100644
> --- a/security/selinux/include/security.h
> +++ b/security/selinux/include/security.h
> @@ -229,7 +229,8 @@ void selinux_policy_cancel(struct selinux_state *state,
>                         struct selinux_policy *policy);
>  int security_read_policy(struct selinux_state *state,
>                          void **data, size_t *len);
> -
> +int security_read_state_kernel(struct selinux_state *state,
> +                              void **data, size_t *len);
>  int security_policycap_supported(struct selinux_state *state,
>                                  unsigned int req_cap);
>
> diff --git a/security/selinux/ss/services.c b/security/selinux/ss/services.c
> index 9704c8a32303..cc8dbc4ed8db 100644
> --- a/security/selinux/ss/services.c
> +++ b/security/selinux/ss/services.c
> @@ -65,6 +65,7 @@
>  #include "ebitmap.h"
>  #include "audit.h"
>  #include "policycap_names.h"
> +#include "ima.h"
>
>  /* Forward declaration. */
>  static int context_struct_to_string(struct policydb *policydb,
> @@ -2180,6 +2181,7 @@ static void selinux_notify_policy_change(struct selinux_state *state,
>         selinux_status_update_policyload(state, seqno);
>         selinux_netlbl_cache_invalidate();
>         selinux_xfrm_notify_policyload();
> +       selinux_ima_measure_state(state);
>  }
>
>  void selinux_policy_commit(struct selinux_state *state,
> @@ -3875,8 +3877,33 @@ int security_netlbl_sid_to_secattr(struct selinux_state *state,
>  }
>  #endif /* CONFIG_NETLABEL */
>
> +/**
> + * __security_read_policy - read the policy.
> + * @policy: SELinux policy
> + * @data: binary policy data
> + * @len: length of data in bytes
> + *
> + */
> +static int __security_read_policy(struct selinux_policy *policy,
> +                                 void *data, size_t *len)
> +{
> +       int rc;
> +       struct policy_file fp;
> +
> +       fp.data = data;
> +       fp.len = *len;
> +
> +       rc = policydb_write(&policy->policydb, &fp);
> +       if (rc)
> +               return rc;
> +
> +       *len = (unsigned long)fp.data - (unsigned long)data;
> +       return 0;
> +}
> +
>  /**
>   * security_read_policy - read the policy.
> + * @state: selinux_state
>   * @data: binary policy data
>   * @len: length of data in bytes
>   *
> @@ -3885,8 +3912,6 @@ int security_read_policy(struct selinux_state *state,
>                          void **data, size_t *len)
>  {
>         struct selinux_policy *policy;
> -       int rc;
> -       struct policy_file fp;
>
>         policy = rcu_dereference_protected(
>                         state->policy, lockdep_is_held(&state->policy_mutex));
> @@ -3898,14 +3923,35 @@ int security_read_policy(struct selinux_state *state,
>         if (!*data)
>                 return -ENOMEM;
>
> -       fp.data = *data;
> -       fp.len = *len;
> +       return __security_read_policy(policy, *data, len);
> +}
>
> -       rc = policydb_write(&policy->policydb, &fp);
> -       if (rc)
> -               return rc;
> +/**
> + * security_read_state_kernel - read the policy.
> + * @state: selinux_state
> + * @data: binary policy data
> + * @len: length of data in bytes
> + *
> + * Allocates kernel memory for reading SELinux policy.
> + * This function is for internal use only and should not
> + * be used for returning data to user space.
> + *
> + * This function must be called with policy_mutex held.
> + */
> +int security_read_state_kernel(struct selinux_state *state,
> +                              void **data, size_t *len)
> +{
> +       struct selinux_policy *policy;
>
> -       *len = (unsigned long)fp.data - (unsigned long)*data;
> -       return 0;
> +       policy = rcu_dereference_protected(
> +                       state->policy, lockdep_is_held(&state->policy_mutex));
> +       if (!policy)
> +               return -EINVAL;
> +
> +       *len = policy->policydb.len;
> +       *data = vmalloc(*len);
> +       if (!*data)
> +               return -ENOMEM;
>
> +       return __security_read_policy(policy, *data, len);
>  }
> --
> 2.17.1
>


-- 
paul moore
www.paul-moore.com

^ permalink raw reply	[flat|nested] 28+ messages in thread

* Re: [PATCH v10 8/8] selinux: include a consumer of the new IMA critical data hook
  2021-01-12 16:27   ` Paul Moore
@ 2021-01-12 18:25     ` Lakshmi Ramasubramanian
  2021-01-13 19:13     ` Mimi Zohar
  1 sibling, 0 replies; 28+ messages in thread
From: Lakshmi Ramasubramanian @ 2021-01-12 18:25 UTC (permalink / raw)
  To: Paul Moore, Tushar Sugandhi
  Cc: zohar, Stephen Smalley, casey, agk, snitzer, gmazyland, tyhicks,
	sashal, James Morris, linux-integrity, selinux,
	linux-security-module, linux-kernel, dm-devel

On 1/12/21 8:27 AM, Paul Moore wrote:
> On Thu, Jan 7, 2021 at 11:07 PM Tushar Sugandhi
> <tusharsu@linux.microsoft.com> wrote:
>> From: Lakshmi Ramasubramanian <nramas@linux.microsoft.com>
>>
>> SELinux stores the active policy in memory, so the changes to this data
>> at runtime would have an impact on the security guarantees provided
>> by SELinux.  Measuring in-memory SELinux policy through IMA subsystem
>> provides a secure way for the attestation service to remotely validate
>> the policy contents at runtime.
>>
>> Measure the hash of the loaded policy by calling the IMA hook
>> ima_measure_critical_data().  Since the size of the loaded policy
>> can be large (several MB), measure the hash of the policy instead of
>> the entire policy to avoid bloating the IMA log entry.
>>
>> To enable SELinux data measurement, the following steps are required:
>>
>> 1, Add "ima_policy=critical_data" to the kernel command line arguments
>>     to enable measuring SELinux data at boot time.
>> For example,
>>    BOOT_IMAGE=/boot/vmlinuz-5.10.0-rc1+ root=UUID=fd643309-a5d2-4ed3-b10d-3c579a5fab2f ro nomodeset security=selinux ima_policy=critical_data
>>
>> 2, Add the following rule to /etc/ima/ima-policy
>>     measure func=CRITICAL_DATA label=selinux
>>
>> Sample measurement of the hash of SELinux policy:
>>
>> To verify the measured data with the current SELinux policy run
>> the following commands and verify the output hash values match.
>>
>>    sha256sum /sys/fs/selinux/policy | cut -d' ' -f 1
>>
>>    grep "selinux-policy-hash" /sys/kernel/security/integrity/ima/ascii_runtime_measurements | tail -1 | cut -d' ' -f 6
>>
>> Note that the actual verification of SELinux policy would require loading
>> the expected policy into an identical kernel on a pristine/known-safe
>> system and run the sha256sum /sys/kernel/selinux/policy there to get
>> the expected hash.
>>
>> Signed-off-by: Lakshmi Ramasubramanian <nramas@linux.microsoft.com>
>> Suggested-by: Stephen Smalley <stephen.smalley.work@gmail.com>
>> Reviewed-by: Tyler Hicks <tyhicks@linux.microsoft.com>
>> ---
>>   Documentation/ABI/testing/ima_policy |  3 +-
>>   security/selinux/Makefile            |  2 +
>>   security/selinux/ima.c               | 64 ++++++++++++++++++++++++++++
>>   security/selinux/include/ima.h       | 24 +++++++++++
>>   security/selinux/include/security.h  |  3 +-
>>   security/selinux/ss/services.c       | 64 ++++++++++++++++++++++++----
>>   6 files changed, 149 insertions(+), 11 deletions(-)
>>   create mode 100644 security/selinux/ima.c
>>   create mode 100644 security/selinux/include/ima.h
> 
> I remain concerned about the possibility of bypassing a measurement by
> tampering with the time, but I appear to be the only one who is
> worried about this so I'm not going to block this patch on those
> grounds.
> 
> Acked-by: Paul Moore <paul@paul-moore.com>

Thanks Paul.

  -lakshmi


^ permalink raw reply	[flat|nested] 28+ messages in thread

* Re: [PATCH v10 8/8] selinux: include a consumer of the new IMA critical data hook
  2021-01-12 16:27   ` Paul Moore
  2021-01-12 18:25     ` Lakshmi Ramasubramanian
@ 2021-01-13 19:13     ` Mimi Zohar
  2021-01-13 19:19       ` Paul Moore
  1 sibling, 1 reply; 28+ messages in thread
From: Mimi Zohar @ 2021-01-13 19:13 UTC (permalink / raw)
  To: Paul Moore, Tushar Sugandhi
  Cc: Stephen Smalley, casey, agk, snitzer, gmazyland, tyhicks, sashal,
	James Morris, nramas, linux-integrity, selinux,
	linux-security-module, linux-kernel, dm-devel

On Tue, 2021-01-12 at 11:27 -0500, Paul Moore wrote:
> On Thu, Jan 7, 2021 at 11:07 PM Tushar Sugandhi
> <tusharsu@linux.microsoft.com> wrote:
> > From: Lakshmi Ramasubramanian <nramas@linux.microsoft.com>
> >
> > SELinux stores the active policy in memory, so the changes to this data
> > at runtime would have an impact on the security guarantees provided
> > by SELinux.  Measuring in-memory SELinux policy through IMA subsystem
> > provides a secure way for the attestation service to remotely validate
> > the policy contents at runtime.
> >
> > Measure the hash of the loaded policy by calling the IMA hook
> > ima_measure_critical_data().  Since the size of the loaded policy
> > can be large (several MB), measure the hash of the policy instead of
> > the entire policy to avoid bloating the IMA log entry.
> >
> > To enable SELinux data measurement, the following steps are required:
> >
> > 1, Add "ima_policy=critical_data" to the kernel command line arguments
> >    to enable measuring SELinux data at boot time.
> > For example,
> >   BOOT_IMAGE=/boot/vmlinuz-5.10.0-rc1+ root=UUID=fd643309-a5d2-4ed3-b10d-3c579a5fab2f ro nomodeset security=selinux ima_policy=critical_data
> >
> > 2, Add the following rule to /etc/ima/ima-policy
> >    measure func=CRITICAL_DATA label=selinux
> >
> > Sample measurement of the hash of SELinux policy:
> >
> > To verify the measured data with the current SELinux policy run
> > the following commands and verify the output hash values match.
> >
> >   sha256sum /sys/fs/selinux/policy | cut -d' ' -f 1
> >
> >   grep "selinux-policy-hash" /sys/kernel/security/integrity/ima/ascii_runtime_measurements | tail -1 | cut -d' ' -f 6
> >
> > Note that the actual verification of SELinux policy would require loading
> > the expected policy into an identical kernel on a pristine/known-safe
> > system and run the sha256sum /sys/kernel/selinux/policy there to get
> > the expected hash.
> >
> > Signed-off-by: Lakshmi Ramasubramanian <nramas@linux.microsoft.com>
> > Suggested-by: Stephen Smalley <stephen.smalley.work@gmail.com>
> > Reviewed-by: Tyler Hicks <tyhicks@linux.microsoft.com>
> > ---
> >  Documentation/ABI/testing/ima_policy |  3 +-
> >  security/selinux/Makefile            |  2 +
> >  security/selinux/ima.c               | 64 ++++++++++++++++++++++++++++
> >  security/selinux/include/ima.h       | 24 +++++++++++
> >  security/selinux/include/security.h  |  3 +-
> >  security/selinux/ss/services.c       | 64 ++++++++++++++++++++++++----
> >  6 files changed, 149 insertions(+), 11 deletions(-)
> >  create mode 100644 security/selinux/ima.c
> >  create mode 100644 security/selinux/include/ima.h
> 
> I remain concerned about the possibility of bypassing a measurement by
> tampering with the time, but I appear to be the only one who is
> worried about this so I'm not going to block this patch on those
> grounds.
> 
> Acked-by: Paul Moore <paul@paul-moore.com>

Thanks, Paul.

Including any unique string would cause the buffer hash to change,
forcing a new measurement.  Perhaps they were concerned with
overflowing a counter.

Mimi

> > +/*
> > + * selinux_ima_measure_state - Measure hash of the SELinux policy
> > + *
> > + * @state: selinux state struct
> > + *
> > + * NOTE: This function must be called with policy_mutex held.
> > + */
> > +void selinux_ima_measure_state(struct selinux_state *state)
> > +{
> > +       struct timespec64 cur_time;
> > +       void *policy = NULL;
> > +       char *policy_event_name = NULL;
> > +       size_t policy_len;
> > +       int rc = 0;
> > +
> > +       /*
> > +        * Measure SELinux policy only after initialization is completed.
> > +        */
> > +       if (!selinux_initialized(state))
> > +               return;
> > +
> > +       /*
> > +        * Pass a unique "event_name" to the IMA hook so that IMA subsystem
> > +        * will always measure the given data.
> > +        */
> > +       ktime_get_real_ts64(&cur_time);
> > +       policy_event_name = kasprintf(GFP_KERNEL, "%s-%lld:%09ld",
> > +                                     "selinux-policy-hash",
> > +                                     cur_time.tv_sec, cur_time.tv_nsec);
> > +       if (!policy_event_name) {
> > +               pr_err("SELinux: %s: event name for policy not allocated.\n",
> > +                      __func__);
> > +               goto out;
> > +       }
> > +


^ permalink raw reply	[flat|nested] 28+ messages in thread

* Re: [PATCH v10 8/8] selinux: include a consumer of the new IMA critical data hook
  2021-01-13 19:13     ` Mimi Zohar
@ 2021-01-13 19:19       ` Paul Moore
  2021-01-13 21:11         ` Mimi Zohar
  0 siblings, 1 reply; 28+ messages in thread
From: Paul Moore @ 2021-01-13 19:19 UTC (permalink / raw)
  To: Mimi Zohar
  Cc: Tushar Sugandhi, Stephen Smalley, casey, agk, snitzer, gmazyland,
	tyhicks, sashal, James Morris, nramas, linux-integrity, selinux,
	linux-security-module, linux-kernel, dm-devel

On Wed, Jan 13, 2021 at 2:13 PM Mimi Zohar <zohar@linux.ibm.com> wrote:
> On Tue, 2021-01-12 at 11:27 -0500, Paul Moore wrote:
> > On Thu, Jan 7, 2021 at 11:07 PM Tushar Sugandhi
> > <tusharsu@linux.microsoft.com> wrote:
> > > From: Lakshmi Ramasubramanian <nramas@linux.microsoft.com>
> > >
> > > SELinux stores the active policy in memory, so the changes to this data
> > > at runtime would have an impact on the security guarantees provided
> > > by SELinux.  Measuring in-memory SELinux policy through IMA subsystem
> > > provides a secure way for the attestation service to remotely validate
> > > the policy contents at runtime.
> > >
> > > Measure the hash of the loaded policy by calling the IMA hook
> > > ima_measure_critical_data().  Since the size of the loaded policy
> > > can be large (several MB), measure the hash of the policy instead of
> > > the entire policy to avoid bloating the IMA log entry.
> > >
> > > To enable SELinux data measurement, the following steps are required:
> > >
> > > 1, Add "ima_policy=critical_data" to the kernel command line arguments
> > >    to enable measuring SELinux data at boot time.
> > > For example,
> > >   BOOT_IMAGE=/boot/vmlinuz-5.10.0-rc1+ root=UUID=fd643309-a5d2-4ed3-b10d-3c579a5fab2f ro nomodeset security=selinux ima_policy=critical_data
> > >
> > > 2, Add the following rule to /etc/ima/ima-policy
> > >    measure func=CRITICAL_DATA label=selinux
> > >
> > > Sample measurement of the hash of SELinux policy:
> > >
> > > To verify the measured data with the current SELinux policy run
> > > the following commands and verify the output hash values match.
> > >
> > >   sha256sum /sys/fs/selinux/policy | cut -d' ' -f 1
> > >
> > >   grep "selinux-policy-hash" /sys/kernel/security/integrity/ima/ascii_runtime_measurements | tail -1 | cut -d' ' -f 6
> > >
> > > Note that the actual verification of SELinux policy would require loading
> > > the expected policy into an identical kernel on a pristine/known-safe
> > > system and run the sha256sum /sys/kernel/selinux/policy there to get
> > > the expected hash.
> > >
> > > Signed-off-by: Lakshmi Ramasubramanian <nramas@linux.microsoft.com>
> > > Suggested-by: Stephen Smalley <stephen.smalley.work@gmail.com>
> > > Reviewed-by: Tyler Hicks <tyhicks@linux.microsoft.com>
> > > ---
> > >  Documentation/ABI/testing/ima_policy |  3 +-
> > >  security/selinux/Makefile            |  2 +
> > >  security/selinux/ima.c               | 64 ++++++++++++++++++++++++++++
> > >  security/selinux/include/ima.h       | 24 +++++++++++
> > >  security/selinux/include/security.h  |  3 +-
> > >  security/selinux/ss/services.c       | 64 ++++++++++++++++++++++++----
> > >  6 files changed, 149 insertions(+), 11 deletions(-)
> > >  create mode 100644 security/selinux/ima.c
> > >  create mode 100644 security/selinux/include/ima.h
> >
> > I remain concerned about the possibility of bypassing a measurement by
> > tampering with the time, but I appear to be the only one who is
> > worried about this so I'm not going to block this patch on those
> > grounds.
> >
> > Acked-by: Paul Moore <paul@paul-moore.com>
>
> Thanks, Paul.
>
> Including any unique string would cause the buffer hash to change,
> forcing a new measurement.  Perhaps they were concerned with
> overflowing a counter.

My understanding is that Lakshmi wanted to force a new measurement
each time and felt using a timestamp would be the best way to do that.
A counter, even if it wraps, would have a different value each time
whereas a timestamp is vulnerable to time adjustments.  While a
properly controlled and audited system could be configured and
monitored to detect such an event (I *think*), why rely on that if it
isn't necessary?

-- 
paul moore
www.paul-moore.com

^ permalink raw reply	[flat|nested] 28+ messages in thread

* Re: [PATCH v10 8/8] selinux: include a consumer of the new IMA critical data hook
  2021-01-13 19:19       ` Paul Moore
@ 2021-01-13 21:11         ` Mimi Zohar
  2021-01-13 22:10           ` Paul Moore
  0 siblings, 1 reply; 28+ messages in thread
From: Mimi Zohar @ 2021-01-13 21:11 UTC (permalink / raw)
  To: Paul Moore
  Cc: Tushar Sugandhi, Stephen Smalley, casey, agk, snitzer, gmazyland,
	tyhicks, sashal, James Morris, nramas, linux-integrity, selinux,
	linux-security-module, linux-kernel, dm-devel

On Wed, 2021-01-13 at 14:19 -0500, Paul Moore wrote:
> On Wed, Jan 13, 2021 at 2:13 PM Mimi Zohar <zohar@linux.ibm.com> wrote:
> > On Tue, 2021-01-12 at 11:27 -0500, Paul Moore wrote:
> > > On Thu, Jan 7, 2021 at 11:07 PM Tushar Sugandhi
> > > <tusharsu@linux.microsoft.com> wrote:
> > > > From: Lakshmi Ramasubramanian <nramas@linux.microsoft.com>
> > > >
> > > > SELinux stores the active policy in memory, so the changes to this data
> > > > at runtime would have an impact on the security guarantees provided
> > > > by SELinux.  Measuring in-memory SELinux policy through IMA subsystem
> > > > provides a secure way for the attestation service to remotely validate
> > > > the policy contents at runtime.
> > > >
> > > > Measure the hash of the loaded policy by calling the IMA hook
> > > > ima_measure_critical_data().  Since the size of the loaded policy
> > > > can be large (several MB), measure the hash of the policy instead of
> > > > the entire policy to avoid bloating the IMA log entry.
> > > >
> > > > To enable SELinux data measurement, the following steps are required:
> > > >
> > > > 1, Add "ima_policy=critical_data" to the kernel command line arguments
> > > >    to enable measuring SELinux data at boot time.
> > > > For example,
> > > >   BOOT_IMAGE=/boot/vmlinuz-5.10.0-rc1+ root=UUID=fd643309-a5d2-4ed3-b10d-3c579a5fab2f ro nomodeset security=selinux ima_policy=critical_data
> > > >
> > > > 2, Add the following rule to /etc/ima/ima-policy
> > > >    measure func=CRITICAL_DATA label=selinux
> > > >
> > > > Sample measurement of the hash of SELinux policy:
> > > >
> > > > To verify the measured data with the current SELinux policy run
> > > > the following commands and verify the output hash values match.
> > > >
> > > >   sha256sum /sys/fs/selinux/policy | cut -d' ' -f 1
> > > >
> > > >   grep "selinux-policy-hash" /sys/kernel/security/integrity/ima/ascii_runtime_measurements | tail -1 | cut -d' ' -f 6
> > > >
> > > > Note that the actual verification of SELinux policy would require loading
> > > > the expected policy into an identical kernel on a pristine/known-safe
> > > > system and run the sha256sum /sys/kernel/selinux/policy there to get
> > > > the expected hash.
> > > >
> > > > Signed-off-by: Lakshmi Ramasubramanian <nramas@linux.microsoft.com>
> > > > Suggested-by: Stephen Smalley <stephen.smalley.work@gmail.com>
> > > > Reviewed-by: Tyler Hicks <tyhicks@linux.microsoft.com>
> > > > ---
> > > >  Documentation/ABI/testing/ima_policy |  3 +-
> > > >  security/selinux/Makefile            |  2 +
> > > >  security/selinux/ima.c               | 64 ++++++++++++++++++++++++++++
> > > >  security/selinux/include/ima.h       | 24 +++++++++++
> > > >  security/selinux/include/security.h  |  3 +-
> > > >  security/selinux/ss/services.c       | 64 ++++++++++++++++++++++++----
> > > >  6 files changed, 149 insertions(+), 11 deletions(-)
> > > >  create mode 100644 security/selinux/ima.c
> > > >  create mode 100644 security/selinux/include/ima.h
> > >
> > > I remain concerned about the possibility of bypassing a measurement by
> > > tampering with the time, but I appear to be the only one who is
> > > worried about this so I'm not going to block this patch on those
> > > grounds.
> > >
> > > Acked-by: Paul Moore <paul@paul-moore.com>
> >
> > Thanks, Paul.
> >
> > Including any unique string would cause the buffer hash to change,
> > forcing a new measurement.  Perhaps they were concerned with
> > overflowing a counter.
> 
> My understanding is that Lakshmi wanted to force a new measurement
> each time and felt using a timestamp would be the best way to do that.
> A counter, even if it wraps, would have a different value each time
> whereas a timestamp is vulnerable to time adjustments.  While a
> properly controlled and audited system could be configured and
> monitored to detect such an event (I *think*), why rely on that if it
> isn't necessary?

Why are you saying that even if the counter wraps a new measurement is
guaranteed.   I agree with the rest of what you said.

Mimi



^ permalink raw reply	[flat|nested] 28+ messages in thread

* Re: [PATCH v10 8/8] selinux: include a consumer of the new IMA critical data hook
  2021-01-13 21:11         ` Mimi Zohar
@ 2021-01-13 22:10           ` Paul Moore
  2021-01-13 23:10             ` Mimi Zohar
  0 siblings, 1 reply; 28+ messages in thread
From: Paul Moore @ 2021-01-13 22:10 UTC (permalink / raw)
  To: Mimi Zohar
  Cc: Tushar Sugandhi, Stephen Smalley, casey, agk, snitzer, gmazyland,
	tyhicks, sashal, James Morris, nramas, linux-integrity, selinux,
	linux-security-module, linux-kernel, dm-devel

On Wed, Jan 13, 2021 at 4:11 PM Mimi Zohar <zohar@linux.ibm.com> wrote:
> On Wed, 2021-01-13 at 14:19 -0500, Paul Moore wrote:
> > On Wed, Jan 13, 2021 at 2:13 PM Mimi Zohar <zohar@linux.ibm.com> wrote:
> > > On Tue, 2021-01-12 at 11:27 -0500, Paul Moore wrote:
> > > > On Thu, Jan 7, 2021 at 11:07 PM Tushar Sugandhi
> > > > <tusharsu@linux.microsoft.com> wrote:
> > > > > From: Lakshmi Ramasubramanian <nramas@linux.microsoft.com>
> > > > >
> > > > > SELinux stores the active policy in memory, so the changes to this data
> > > > > at runtime would have an impact on the security guarantees provided
> > > > > by SELinux.  Measuring in-memory SELinux policy through IMA subsystem
> > > > > provides a secure way for the attestation service to remotely validate
> > > > > the policy contents at runtime.
> > > > >
> > > > > Measure the hash of the loaded policy by calling the IMA hook
> > > > > ima_measure_critical_data().  Since the size of the loaded policy
> > > > > can be large (several MB), measure the hash of the policy instead of
> > > > > the entire policy to avoid bloating the IMA log entry.
> > > > >
> > > > > To enable SELinux data measurement, the following steps are required:
> > > > >
> > > > > 1, Add "ima_policy=critical_data" to the kernel command line arguments
> > > > >    to enable measuring SELinux data at boot time.
> > > > > For example,
> > > > >   BOOT_IMAGE=/boot/vmlinuz-5.10.0-rc1+ root=UUID=fd643309-a5d2-4ed3-b10d-3c579a5fab2f ro nomodeset security=selinux ima_policy=critical_data
> > > > >
> > > > > 2, Add the following rule to /etc/ima/ima-policy
> > > > >    measure func=CRITICAL_DATA label=selinux
> > > > >
> > > > > Sample measurement of the hash of SELinux policy:
> > > > >
> > > > > To verify the measured data with the current SELinux policy run
> > > > > the following commands and verify the output hash values match.
> > > > >
> > > > >   sha256sum /sys/fs/selinux/policy | cut -d' ' -f 1
> > > > >
> > > > >   grep "selinux-policy-hash" /sys/kernel/security/integrity/ima/ascii_runtime_measurements | tail -1 | cut -d' ' -f 6
> > > > >
> > > > > Note that the actual verification of SELinux policy would require loading
> > > > > the expected policy into an identical kernel on a pristine/known-safe
> > > > > system and run the sha256sum /sys/kernel/selinux/policy there to get
> > > > > the expected hash.
> > > > >
> > > > > Signed-off-by: Lakshmi Ramasubramanian <nramas@linux.microsoft.com>
> > > > > Suggested-by: Stephen Smalley <stephen.smalley.work@gmail.com>
> > > > > Reviewed-by: Tyler Hicks <tyhicks@linux.microsoft.com>
> > > > > ---
> > > > >  Documentation/ABI/testing/ima_policy |  3 +-
> > > > >  security/selinux/Makefile            |  2 +
> > > > >  security/selinux/ima.c               | 64 ++++++++++++++++++++++++++++
> > > > >  security/selinux/include/ima.h       | 24 +++++++++++
> > > > >  security/selinux/include/security.h  |  3 +-
> > > > >  security/selinux/ss/services.c       | 64 ++++++++++++++++++++++++----
> > > > >  6 files changed, 149 insertions(+), 11 deletions(-)
> > > > >  create mode 100644 security/selinux/ima.c
> > > > >  create mode 100644 security/selinux/include/ima.h
> > > >
> > > > I remain concerned about the possibility of bypassing a measurement by
> > > > tampering with the time, but I appear to be the only one who is
> > > > worried about this so I'm not going to block this patch on those
> > > > grounds.
> > > >
> > > > Acked-by: Paul Moore <paul@paul-moore.com>
> > >
> > > Thanks, Paul.
> > >
> > > Including any unique string would cause the buffer hash to change,
> > > forcing a new measurement.  Perhaps they were concerned with
> > > overflowing a counter.
> >
> > My understanding is that Lakshmi wanted to force a new measurement
> > each time and felt using a timestamp would be the best way to do that.
> > A counter, even if it wraps, would have a different value each time
> > whereas a timestamp is vulnerable to time adjustments.  While a
> > properly controlled and audited system could be configured and
> > monitored to detect such an event (I *think*), why rely on that if it
> > isn't necessary?
>
> Why are you saying that even if the counter wraps a new measurement is
> guaranteed.   I agree with the rest of what you said.

I was assuming that the IMA code simply compares the passed
"policy_event_name" value to the previous value, if they are different
a new measurement is taken, if they are the same the measurement
request is ignored.  If this is the case the counter value is only
important in as much as that it is different from the previous value,
even simply toggling a single bit back and forth would suffice in this
case.  IMA doesn't keep a record of every previous "policy_event_name"
value does it?  Am I misunderstanding how
ima_measure_critical_data(...) works?

-- 
paul moore
www.paul-moore.com

^ permalink raw reply	[flat|nested] 28+ messages in thread

* Re: [PATCH v10 8/8] selinux: include a consumer of the new IMA critical data hook
  2021-01-13 22:10           ` Paul Moore
@ 2021-01-13 23:10             ` Mimi Zohar
  2021-01-14  2:40               ` Paul Moore
  0 siblings, 1 reply; 28+ messages in thread
From: Mimi Zohar @ 2021-01-13 23:10 UTC (permalink / raw)
  To: Paul Moore
  Cc: Tushar Sugandhi, Stephen Smalley, casey, agk, snitzer, gmazyland,
	tyhicks, sashal, James Morris, nramas, linux-integrity, selinux,
	linux-security-module, linux-kernel, dm-devel

On Wed, 2021-01-13 at 17:10 -0500, Paul Moore wrote:
> On Wed, Jan 13, 2021 at 4:11 PM Mimi Zohar <zohar@linux.ibm.com> wrote:
> > On Wed, 2021-01-13 at 14:19 -0500, Paul Moore wrote:
> > > On Wed, Jan 13, 2021 at 2:13 PM Mimi Zohar <zohar@linux.ibm.com> wrote:
> > > > On Tue, 2021-01-12 at 11:27 -0500, Paul Moore wrote:
> > > > > On Thu, Jan 7, 2021 at 11:07 PM Tushar Sugandhi
> > > > > <tusharsu@linux.microsoft.com> wrote:
> > > > > > From: Lakshmi Ramasubramanian <nramas@linux.microsoft.com>
> > > > > >
> > > > > > SELinux stores the active policy in memory, so the changes to this data
> > > > > > at runtime would have an impact on the security guarantees provided
> > > > > > by SELinux.  Measuring in-memory SELinux policy through IMA subsystem
> > > > > > provides a secure way for the attestation service to remotely validate
> > > > > > the policy contents at runtime.
> > > > > >
> > > > > > Measure the hash of the loaded policy by calling the IMA hook
> > > > > > ima_measure_critical_data().  Since the size of the loaded policy
> > > > > > can be large (several MB), measure the hash of the policy instead of
> > > > > > the entire policy to avoid bloating the IMA log entry.
> > > > > >
> > > > > > To enable SELinux data measurement, the following steps are required:
> > > > > >
> > > > > > 1, Add "ima_policy=critical_data" to the kernel command line arguments
> > > > > >    to enable measuring SELinux data at boot time.
> > > > > > For example,
> > > > > >   BOOT_IMAGE=/boot/vmlinuz-5.10.0-rc1+ root=UUID=fd643309-a5d2-4ed3-b10d-3c579a5fab2f ro nomodeset security=selinux ima_policy=critical_data
> > > > > >
> > > > > > 2, Add the following rule to /etc/ima/ima-policy
> > > > > >    measure func=CRITICAL_DATA label=selinux
> > > > > >
> > > > > > Sample measurement of the hash of SELinux policy:
> > > > > >
> > > > > > To verify the measured data with the current SELinux policy run
> > > > > > the following commands and verify the output hash values match.
> > > > > >
> > > > > >   sha256sum /sys/fs/selinux/policy | cut -d' ' -f 1
> > > > > >
> > > > > >   grep "selinux-policy-hash" /sys/kernel/security/integrity/ima/ascii_runtime_measurements | tail -1 | cut -d' ' -f 6
> > > > > >
> > > > > > Note that the actual verification of SELinux policy would require loading
> > > > > > the expected policy into an identical kernel on a pristine/known-safe
> > > > > > system and run the sha256sum /sys/kernel/selinux/policy there to get
> > > > > > the expected hash.
> > > > > >
> > > > > > Signed-off-by: Lakshmi Ramasubramanian <nramas@linux.microsoft.com>
> > > > > > Suggested-by: Stephen Smalley <stephen.smalley.work@gmail.com>
> > > > > > Reviewed-by: Tyler Hicks <tyhicks@linux.microsoft.com>
> > > > > > ---
> > > > > >  Documentation/ABI/testing/ima_policy |  3 +-
> > > > > >  security/selinux/Makefile            |  2 +
> > > > > >  security/selinux/ima.c               | 64 ++++++++++++++++++++++++++++
> > > > > >  security/selinux/include/ima.h       | 24 +++++++++++
> > > > > >  security/selinux/include/security.h  |  3 +-
> > > > > >  security/selinux/ss/services.c       | 64 ++++++++++++++++++++++++----
> > > > > >  6 files changed, 149 insertions(+), 11 deletions(-)
> > > > > >  create mode 100644 security/selinux/ima.c
> > > > > >  create mode 100644 security/selinux/include/ima.h
> > > > >
> > > > > I remain concerned about the possibility of bypassing a measurement by
> > > > > tampering with the time, but I appear to be the only one who is
> > > > > worried about this so I'm not going to block this patch on those
> > > > > grounds.
> > > > >
> > > > > Acked-by: Paul Moore <paul@paul-moore.com>
> > > >
> > > > Thanks, Paul.
> > > >
> > > > Including any unique string would cause the buffer hash to change,
> > > > forcing a new measurement.  Perhaps they were concerned with
> > > > overflowing a counter.
> > >
> > > My understanding is that Lakshmi wanted to force a new measurement
> > > each time and felt using a timestamp would be the best way to do that.
> > > A counter, even if it wraps, would have a different value each time
> > > whereas a timestamp is vulnerable to time adjustments.  While a
> > > properly controlled and audited system could be configured and
> > > monitored to detect such an event (I *think*), why rely on that if it
> > > isn't necessary?
> >
> > Why are you saying that even if the counter wraps a new measurement is
> > guaranteed.   I agree with the rest of what you said.
> 
> I was assuming that the IMA code simply compares the passed
> "policy_event_name" value to the previous value, if they are different
> a new measurement is taken, if they are the same the measurement
> request is ignored.  If this is the case the counter value is only
> important in as much as that it is different from the previous value,
> even simply toggling a single bit back and forth would suffice in this
> case.  IMA doesn't keep a record of every previous "policy_event_name"
> value does it?  Am I misunderstanding how
> ima_measure_critical_data(...) works?

Originally, there was quite a bit of discussion as to how much or how
little should be measured for a number of reasons.  One reason is that
the TPM is relatively slow.  Another reason is to limit the size of the
measurement list.  For this reason, duplicate hashes aren't added to
the measurement list or extended into the TPM.

When a dentry is removed from cache, its also removed from IMA's iint
cache.  A subsequent file read would result in adding the measurement
and extending the TPM again.  ima_lookup_digest_entry() is called to
prevent adding the duplicate entry. 

Lakshmi is trying to address the situation where an event changes a
value, but then is restored to the original value.  The original and
subsequent events are measured, but restoring to the original value
isn't re-measured.  This isn't any different than when a file is
modified and then reverted.

Instead of changing the name like this, which doesn't work for files,
allowing duplicate measurements should be generic, based on policy.

Mimi


^ permalink raw reply	[flat|nested] 28+ messages in thread

* Re: [PATCH v10 5/8] IMA: limit critical data measurement based on a label
  2021-01-08  4:07 ` [PATCH v10 5/8] IMA: limit critical data measurement based on a label Tushar Sugandhi
@ 2021-01-14  2:09   ` Mimi Zohar
  2021-01-14 17:57     ` Tushar Sugandhi
  0 siblings, 1 reply; 28+ messages in thread
From: Mimi Zohar @ 2021-01-14  2:09 UTC (permalink / raw)
  To: Tushar Sugandhi, stephen.smalley.work, casey, agk, snitzer,
	gmazyland, paul
  Cc: tyhicks, sashal, jmorris, nramas, linux-integrity, selinux,
	linux-security-module, linux-kernel, dm-devel

On Thu, 2021-01-07 at 20:07 -0800, Tushar Sugandhi wrote:
> Integrity critical data may belong to a single subsystem or it may
> arise from cross subsystem interaction.  Currently there is no mechanism
> to group or limit the data based on certain label.  Limiting and
> grouping critical data based on a label would make it flexible and
> configurable to measure.
> 
> Define "label:=", a new IMA policy condition, for the IMA func
> CRITICAL_DATA to allow grouping and limiting measurement of integrity
> critical data.
> 
> Limit the measurement to the labels that are specified in the IMA
> policy - CRITICAL_DATA+"label:=".  If "label:=" is not provided with
> the func CRITICAL_DATA, measure all the input integrity critical data.
> 
> Signed-off-by: Tushar Sugandhi <tusharsu@linux.microsoft.com>
> Reviewed-by: Tyler Hicks <tyhicks@linux.microsoft.com>

This is looking a lot better.

thanks,

Mimi


^ permalink raw reply	[flat|nested] 28+ messages in thread

* Re: [PATCH v10 8/8] selinux: include a consumer of the new IMA critical data hook
  2021-01-13 23:10             ` Mimi Zohar
@ 2021-01-14  2:40               ` Paul Moore
  2021-01-14  2:49                 ` Mimi Zohar
  0 siblings, 1 reply; 28+ messages in thread
From: Paul Moore @ 2021-01-14  2:40 UTC (permalink / raw)
  To: Mimi Zohar
  Cc: Tushar Sugandhi, Stephen Smalley, casey, agk, snitzer, gmazyland,
	tyhicks, sashal, James Morris, nramas, linux-integrity, selinux,
	linux-security-module, linux-kernel, dm-devel

On Wed, Jan 13, 2021 at 6:11 PM Mimi Zohar <zohar@linux.ibm.com> wrote:
> On Wed, 2021-01-13 at 17:10 -0500, Paul Moore wrote:
> > On Wed, Jan 13, 2021 at 4:11 PM Mimi Zohar <zohar@linux.ibm.com> wrote:
> > > On Wed, 2021-01-13 at 14:19 -0500, Paul Moore wrote:
> > > > On Wed, Jan 13, 2021 at 2:13 PM Mimi Zohar <zohar@linux.ibm.com> wrote:
> > > > > On Tue, 2021-01-12 at 11:27 -0500, Paul Moore wrote:
> > > > > > On Thu, Jan 7, 2021 at 11:07 PM Tushar Sugandhi
> > > > > > <tusharsu@linux.microsoft.com> wrote:
> > > > > > > From: Lakshmi Ramasubramanian <nramas@linux.microsoft.com>
> > > > > > >
> > > > > > > SELinux stores the active policy in memory, so the changes to this data
> > > > > > > at runtime would have an impact on the security guarantees provided
> > > > > > > by SELinux.  Measuring in-memory SELinux policy through IMA subsystem
> > > > > > > provides a secure way for the attestation service to remotely validate
> > > > > > > the policy contents at runtime.
> > > > > > >
> > > > > > > Measure the hash of the loaded policy by calling the IMA hook
> > > > > > > ima_measure_critical_data().  Since the size of the loaded policy
> > > > > > > can be large (several MB), measure the hash of the policy instead of
> > > > > > > the entire policy to avoid bloating the IMA log entry.
> > > > > > >
> > > > > > > To enable SELinux data measurement, the following steps are required:
> > > > > > >
> > > > > > > 1, Add "ima_policy=critical_data" to the kernel command line arguments
> > > > > > >    to enable measuring SELinux data at boot time.
> > > > > > > For example,
> > > > > > >   BOOT_IMAGE=/boot/vmlinuz-5.10.0-rc1+ root=UUID=fd643309-a5d2-4ed3-b10d-3c579a5fab2f ro nomodeset security=selinux ima_policy=critical_data
> > > > > > >
> > > > > > > 2, Add the following rule to /etc/ima/ima-policy
> > > > > > >    measure func=CRITICAL_DATA label=selinux
> > > > > > >
> > > > > > > Sample measurement of the hash of SELinux policy:
> > > > > > >
> > > > > > > To verify the measured data with the current SELinux policy run
> > > > > > > the following commands and verify the output hash values match.
> > > > > > >
> > > > > > >   sha256sum /sys/fs/selinux/policy | cut -d' ' -f 1
> > > > > > >
> > > > > > >   grep "selinux-policy-hash" /sys/kernel/security/integrity/ima/ascii_runtime_measurements | tail -1 | cut -d' ' -f 6
> > > > > > >
> > > > > > > Note that the actual verification of SELinux policy would require loading
> > > > > > > the expected policy into an identical kernel on a pristine/known-safe
> > > > > > > system and run the sha256sum /sys/kernel/selinux/policy there to get
> > > > > > > the expected hash.
> > > > > > >
> > > > > > > Signed-off-by: Lakshmi Ramasubramanian <nramas@linux.microsoft.com>
> > > > > > > Suggested-by: Stephen Smalley <stephen.smalley.work@gmail.com>
> > > > > > > Reviewed-by: Tyler Hicks <tyhicks@linux.microsoft.com>
> > > > > > > ---
> > > > > > >  Documentation/ABI/testing/ima_policy |  3 +-
> > > > > > >  security/selinux/Makefile            |  2 +
> > > > > > >  security/selinux/ima.c               | 64 ++++++++++++++++++++++++++++
> > > > > > >  security/selinux/include/ima.h       | 24 +++++++++++
> > > > > > >  security/selinux/include/security.h  |  3 +-
> > > > > > >  security/selinux/ss/services.c       | 64 ++++++++++++++++++++++++----
> > > > > > >  6 files changed, 149 insertions(+), 11 deletions(-)
> > > > > > >  create mode 100644 security/selinux/ima.c
> > > > > > >  create mode 100644 security/selinux/include/ima.h
> > > > > >
> > > > > > I remain concerned about the possibility of bypassing a measurement by
> > > > > > tampering with the time, but I appear to be the only one who is
> > > > > > worried about this so I'm not going to block this patch on those
> > > > > > grounds.
> > > > > >
> > > > > > Acked-by: Paul Moore <paul@paul-moore.com>
> > > > >
> > > > > Thanks, Paul.
> > > > >
> > > > > Including any unique string would cause the buffer hash to change,
> > > > > forcing a new measurement.  Perhaps they were concerned with
> > > > > overflowing a counter.
> > > >
> > > > My understanding is that Lakshmi wanted to force a new measurement
> > > > each time and felt using a timestamp would be the best way to do that.
> > > > A counter, even if it wraps, would have a different value each time
> > > > whereas a timestamp is vulnerable to time adjustments.  While a
> > > > properly controlled and audited system could be configured and
> > > > monitored to detect such an event (I *think*), why rely on that if it
> > > > isn't necessary?
> > >
> > > Why are you saying that even if the counter wraps a new measurement is
> > > guaranteed.   I agree with the rest of what you said.
> >
> > I was assuming that the IMA code simply compares the passed
> > "policy_event_name" value to the previous value, if they are different
> > a new measurement is taken, if they are the same the measurement
> > request is ignored.  If this is the case the counter value is only
> > important in as much as that it is different from the previous value,
> > even simply toggling a single bit back and forth would suffice in this
> > case.  IMA doesn't keep a record of every previous "policy_event_name"
> > value does it?  Am I misunderstanding how
> > ima_measure_critical_data(...) works?
>
> Originally, there was quite a bit of discussion as to how much or how
> little should be measured for a number of reasons.  One reason is that
> the TPM is relatively slow.  Another reason is to limit the size of the
> measurement list.  For this reason, duplicate hashes aren't added to
> the measurement list or extended into the TPM.
>
> When a dentry is removed from cache, its also removed from IMA's iint
> cache.  A subsequent file read would result in adding the measurement
> and extending the TPM again.  ima_lookup_digest_entry() is called to
> prevent adding the duplicate entry.
>
> Lakshmi is trying to address the situation where an event changes a
> value, but then is restored to the original value.  The original and
> subsequent events are measured, but restoring to the original value
> isn't re-measured.  This isn't any different than when a file is
> modified and then reverted.
>
> Instead of changing the name like this, which doesn't work for files,
> allowing duplicate measurements should be generic, based on policy.

Perhaps it is just the end of the day and I'm a bit tired, but I just
read all of the above and I have no idea what your current thoughts
are regarding this patch.

-- 
paul moore
www.paul-moore.com

^ permalink raw reply	[flat|nested] 28+ messages in thread

* Re: [PATCH v10 8/8] selinux: include a consumer of the new IMA critical data hook
  2021-01-14  2:40               ` Paul Moore
@ 2021-01-14  2:49                 ` Mimi Zohar
  2021-01-14 16:22                   ` Lakshmi Ramasubramanian
  0 siblings, 1 reply; 28+ messages in thread
From: Mimi Zohar @ 2021-01-14  2:49 UTC (permalink / raw)
  To: Paul Moore
  Cc: Tushar Sugandhi, Stephen Smalley, casey, agk, snitzer, gmazyland,
	tyhicks, sashal, James Morris, nramas, linux-integrity, selinux,
	linux-security-module, linux-kernel, dm-devel

On Wed, 2021-01-13 at 21:40 -0500, Paul Moore wrote:
> On Wed, Jan 13, 2021 at 6:11 PM Mimi Zohar <zohar@linux.ibm.com> wrote:
> > On Wed, 2021-01-13 at 17:10 -0500, Paul Moore wrote:
> > > On Wed, Jan 13, 2021 at 4:11 PM Mimi Zohar <zohar@linux.ibm.com> wrote:
> > > > On Wed, 2021-01-13 at 14:19 -0500, Paul Moore wrote:
> > > > > On Wed, Jan 13, 2021 at 2:13 PM Mimi Zohar <zohar@linux.ibm.com> wrote:
> > > > > > On Tue, 2021-01-12 at 11:27 -0500, Paul Moore wrote:
> > > > > > > On Thu, Jan 7, 2021 at 11:07 PM Tushar Sugandhi
> > > > > > > <tusharsu@linux.microsoft.com> wrote:
> > > > > > > > From: Lakshmi Ramasubramanian <nramas@linux.microsoft.com>
> > > > > > > >
> > > > > > > > SELinux stores the active policy in memory, so the changes to this data
> > > > > > > > at runtime would have an impact on the security guarantees provided
> > > > > > > > by SELinux.  Measuring in-memory SELinux policy through IMA subsystem
> > > > > > > > provides a secure way for the attestation service to remotely validate
> > > > > > > > the policy contents at runtime.
> > > > > > > >
> > > > > > > > Measure the hash of the loaded policy by calling the IMA hook
> > > > > > > > ima_measure_critical_data().  Since the size of the loaded policy
> > > > > > > > can be large (several MB), measure the hash of the policy instead of
> > > > > > > > the entire policy to avoid bloating the IMA log entry.
> > > > > > > >
> > > > > > > > To enable SELinux data measurement, the following steps are required:
> > > > > > > >
> > > > > > > > 1, Add "ima_policy=critical_data" to the kernel command line arguments
> > > > > > > >    to enable measuring SELinux data at boot time.
> > > > > > > > For example,
> > > > > > > >   BOOT_IMAGE=/boot/vmlinuz-5.10.0-rc1+ root=UUID=fd643309-a5d2-4ed3-b10d-3c579a5fab2f ro nomodeset security=selinux ima_policy=critical_data
> > > > > > > >
> > > > > > > > 2, Add the following rule to /etc/ima/ima-policy
> > > > > > > >    measure func=CRITICAL_DATA label=selinux
> > > > > > > >
> > > > > > > > Sample measurement of the hash of SELinux policy:
> > > > > > > >
> > > > > > > > To verify the measured data with the current SELinux policy run
> > > > > > > > the following commands and verify the output hash values match.
> > > > > > > >
> > > > > > > >   sha256sum /sys/fs/selinux/policy | cut -d' ' -f 1
> > > > > > > >
> > > > > > > >   grep "selinux-policy-hash" /sys/kernel/security/integrity/ima/ascii_runtime_measurements | tail -1 | cut -d' ' -f 6
> > > > > > > >
> > > > > > > > Note that the actual verification of SELinux policy would require loading
> > > > > > > > the expected policy into an identical kernel on a pristine/known-safe
> > > > > > > > system and run the sha256sum /sys/kernel/selinux/policy there to get
> > > > > > > > the expected hash.
> > > > > > > >
> > > > > > > > Signed-off-by: Lakshmi Ramasubramanian <nramas@linux.microsoft.com>
> > > > > > > > Suggested-by: Stephen Smalley <stephen.smalley.work@gmail.com>
> > > > > > > > Reviewed-by: Tyler Hicks <tyhicks@linux.microsoft.com>
> > > > > > > > ---
> > > > > > > >  Documentation/ABI/testing/ima_policy |  3 +-
> > > > > > > >  security/selinux/Makefile            |  2 +
> > > > > > > >  security/selinux/ima.c               | 64 ++++++++++++++++++++++++++++
> > > > > > > >  security/selinux/include/ima.h       | 24 +++++++++++
> > > > > > > >  security/selinux/include/security.h  |  3 +-
> > > > > > > >  security/selinux/ss/services.c       | 64 ++++++++++++++++++++++++----
> > > > > > > >  6 files changed, 149 insertions(+), 11 deletions(-)
> > > > > > > >  create mode 100644 security/selinux/ima.c
> > > > > > > >  create mode 100644 security/selinux/include/ima.h
> > > > > > >
> > > > > > > I remain concerned about the possibility of bypassing a measurement by
> > > > > > > tampering with the time, but I appear to be the only one who is
> > > > > > > worried about this so I'm not going to block this patch on those
> > > > > > > grounds.
> > > > > > >
> > > > > > > Acked-by: Paul Moore <paul@paul-moore.com>
> > > > > >
> > > > > > Thanks, Paul.
> > > > > >
> > > > > > Including any unique string would cause the buffer hash to change,
> > > > > > forcing a new measurement.  Perhaps they were concerned with
> > > > > > overflowing a counter.
> > > > >
> > > > > My understanding is that Lakshmi wanted to force a new measurement
> > > > > each time and felt using a timestamp would be the best way to do that.
> > > > > A counter, even if it wraps, would have a different value each time
> > > > > whereas a timestamp is vulnerable to time adjustments.  While a
> > > > > properly controlled and audited system could be configured and
> > > > > monitored to detect such an event (I *think*), why rely on that if it
> > > > > isn't necessary?
> > > >
> > > > Why are you saying that even if the counter wraps a new measurement is
> > > > guaranteed.   I agree with the rest of what you said.
> > >
> > > I was assuming that the IMA code simply compares the passed
> > > "policy_event_name" value to the previous value, if they are different
> > > a new measurement is taken, if they are the same the measurement
> > > request is ignored.  If this is the case the counter value is only
> > > important in as much as that it is different from the previous value,
> > > even simply toggling a single bit back and forth would suffice in this
> > > case.  IMA doesn't keep a record of every previous "policy_event_name"
> > > value does it?  Am I misunderstanding how
> > > ima_measure_critical_data(...) works?
> >
> > Originally, there was quite a bit of discussion as to how much or how
> > little should be measured for a number of reasons.  One reason is that
> > the TPM is relatively slow.  Another reason is to limit the size of the
> > measurement list.  For this reason, duplicate hashes aren't added to
> > the measurement list or extended into the TPM.
> >
> > When a dentry is removed from cache, its also removed from IMA's iint
> > cache.  A subsequent file read would result in adding the measurement
> > and extending the TPM again.  ima_lookup_digest_entry() is called to
> > prevent adding the duplicate entry.
> >
> > Lakshmi is trying to address the situation where an event changes a
> > value, but then is restored to the original value.  The original and
> > subsequent events are measured, but restoring to the original value
> > isn't re-measured.  This isn't any different than when a file is
> > modified and then reverted.
> >
> > Instead of changing the name like this, which doesn't work for files,
> > allowing duplicate measurements should be generic, based on policy.
> 
> Perhaps it is just the end of the day and I'm a bit tired, but I just
> read all of the above and I have no idea what your current thoughts
> are regarding this patch.

Other than appending the timestamp, which is a hack, the patch is fine.
Support for re-measuring an event can be upstreamed independently.

Mimi


^ permalink raw reply	[flat|nested] 28+ messages in thread

* Re: [PATCH v10 8/8] selinux: include a consumer of the new IMA critical data hook
  2021-01-14  2:49                 ` Mimi Zohar
@ 2021-01-14 16:22                   ` Lakshmi Ramasubramanian
  2021-01-14 16:44                     ` Mimi Zohar
  0 siblings, 1 reply; 28+ messages in thread
From: Lakshmi Ramasubramanian @ 2021-01-14 16:22 UTC (permalink / raw)
  To: Mimi Zohar, Paul Moore
  Cc: Tushar Sugandhi, Stephen Smalley, casey, agk, snitzer, gmazyland,
	tyhicks, sashal, James Morris, linux-integrity, selinux,
	linux-security-module, linux-kernel, dm-devel

On 1/13/21 6:49 PM, Mimi Zohar wrote:

Hi Mimi,

>>>>>>>> I remain concerned about the possibility of bypassing a measurement by
>>>>>>>> tampering with the time, but I appear to be the only one who is
>>>>>>>> worried about this so I'm not going to block this patch on those
>>>>>>>> grounds.
>>>>>>>>
>>>>>>>> Acked-by: Paul Moore <paul@paul-moore.com>
>>>>>>>
>>>>>>> Thanks, Paul.
>>>>>>>
>>>>>>> Including any unique string would cause the buffer hash to change,
>>>>>>> forcing a new measurement.  Perhaps they were concerned with
>>>>>>> overflowing a counter.
>>>>>>
>>>>>> My understanding is that Lakshmi wanted to force a new measurement
>>>>>> each time and felt using a timestamp would be the best way to do that.
>>>>>> A counter, even if it wraps, would have a different value each time
>>>>>> whereas a timestamp is vulnerable to time adjustments.  While a
>>>>>> properly controlled and audited system could be configured and
>>>>>> monitored to detect such an event (I *think*), why rely on that if it
>>>>>> isn't necessary?
>>>>>
>>>>> Why are you saying that even if the counter wraps a new measurement is
>>>>> guaranteed.   I agree with the rest of what you said.
>>>>
>>>> I was assuming that the IMA code simply compares the passed
>>>> "policy_event_name" value to the previous value, if they are different
>>>> a new measurement is taken, if they are the same the measurement
>>>> request is ignored.  If this is the case the counter value is only
>>>> important in as much as that it is different from the previous value,
>>>> even simply toggling a single bit back and forth would suffice in this
>>>> case.  IMA doesn't keep a record of every previous "policy_event_name"
>>>> value does it?  Am I misunderstanding how
>>>> ima_measure_critical_data(...) works?
>>>
>>> Originally, there was quite a bit of discussion as to how much or how
>>> little should be measured for a number of reasons.  One reason is that
>>> the TPM is relatively slow.  Another reason is to limit the size of the
>>> measurement list.  For this reason, duplicate hashes aren't added to
>>> the measurement list or extended into the TPM.
>>>
>>> When a dentry is removed from cache, its also removed from IMA's iint
>>> cache.  A subsequent file read would result in adding the measurement
>>> and extending the TPM again.  ima_lookup_digest_entry() is called to
>>> prevent adding the duplicate entry.
>>>
>>> Lakshmi is trying to address the situation where an event changes a
>>> value, but then is restored to the original value.  The original and
>>> subsequent events are measured, but restoring to the original value
>>> isn't re-measured.  This isn't any different than when a file is
>>> modified and then reverted.
>>>
>>> Instead of changing the name like this, which doesn't work for files,
>>> allowing duplicate measurements should be generic, based on policy.
>>
>> Perhaps it is just the end of the day and I'm a bit tired, but I just
>> read all of the above and I have no idea what your current thoughts
>> are regarding this patch.
> 
> Other than appending the timestamp, which is a hack, the patch is fine.
> Support for re-measuring an event can be upstreamed independently.
> 

Thanks for clarifying the details related to duplicate measurement 
detection and re-measuring.

I will keep the timestamp for the time being, even though its a hack, as 
it helps with re-measuring state changes in SELinux. We will add support 
for "policy driven" re-measurement as a subsequent patch series.

thanks,
  -lakshmi

^ permalink raw reply	[flat|nested] 28+ messages in thread

* Re: [PATCH v10 8/8] selinux: include a consumer of the new IMA critical data hook
  2021-01-14 16:22                   ` Lakshmi Ramasubramanian
@ 2021-01-14 16:44                     ` Mimi Zohar
  2021-01-14 16:50                       ` Mimi Zohar
  2021-01-14 16:51                       ` Paul Moore
  0 siblings, 2 replies; 28+ messages in thread
From: Mimi Zohar @ 2021-01-14 16:44 UTC (permalink / raw)
  To: Lakshmi Ramasubramanian, Paul Moore, Sasha Levin
  Cc: Tushar Sugandhi, Stephen Smalley, casey, agk, snitzer, gmazyland,
	tyhicks, sashal, James Morris, linux-integrity, selinux,
	linux-security-module, linux-kernel, dm-devel

[Cc'ing Sasha]

Hi Lakshmi,

On Thu, 2021-01-14 at 08:22 -0800, Lakshmi Ramasubramanian wrote:
> On 1/13/21 6:49 PM, Mimi Zohar wrote:

> >>> Lakshmi is trying to address the situation where an event changes a
> >>> value, but then is restored to the original value.  The original and
> >>> subsequent events are measured, but restoring to the original value
> >>> isn't re-measured.  This isn't any different than when a file is
> >>> modified and then reverted.
> >>>
> >>> Instead of changing the name like this, which doesn't work for files,
> >>> allowing duplicate measurements should be generic, based on policy.
> >>
> >> Perhaps it is just the end of the day and I'm a bit tired, but I just
> >> read all of the above and I have no idea what your current thoughts
> >> are regarding this patch.
> > 
> > Other than appending the timestamp, which is a hack, the patch is fine.
> > Support for re-measuring an event can be upstreamed independently.
> > 
> 
> Thanks for clarifying the details related to duplicate measurement 
> detection and re-measuring.
> 
> I will keep the timestamp for the time being, even though its a hack, as 
> it helps with re-measuring state changes in SELinux. We will add support 
> for "policy driven" re-measurement as a subsequent patch series.

Once including the timestamp is upstreamed, removing it will be
difficult, especially if different userspace applications are dependent
on it.  Unless everyone is on board that removing the timestamp
wouldn't be considered a regression, it cannot be upstreamed.

thanks,

Mimi


^ permalink raw reply	[flat|nested] 28+ messages in thread

* Re: [PATCH v10 8/8] selinux: include a consumer of the new IMA critical data hook
  2021-01-14 16:44                     ` Mimi Zohar
@ 2021-01-14 16:50                       ` Mimi Zohar
  2021-01-14 17:48                         ` Lakshmi Ramasubramanian
  2021-01-14 16:51                       ` Paul Moore
  1 sibling, 1 reply; 28+ messages in thread
From: Mimi Zohar @ 2021-01-14 16:50 UTC (permalink / raw)
  To: Lakshmi Ramasubramanian, Paul Moore, Sasha Levin
  Cc: Tushar Sugandhi, Stephen Smalley, casey, agk, snitzer, gmazyland,
	tyhicks, James Morris, linux-integrity, selinux,
	linux-security-module, linux-kernel, dm-devel

On Thu, 2021-01-14 at 11:44 -0500, Mimi Zohar wrote:
> [Cc'ing Sasha]
> 
> Hi Lakshmi,
> 
> On Thu, 2021-01-14 at 08:22 -0800, Lakshmi Ramasubramanian wrote:
> > On 1/13/21 6:49 PM, Mimi Zohar wrote:
> 
> > >>> Lakshmi is trying to address the situation where an event changes a
> > >>> value, but then is restored to the original value.  The original and
> > >>> subsequent events are measured, but restoring to the original value
> > >>> isn't re-measured.  This isn't any different than when a file is
> > >>> modified and then reverted.
> > >>>
> > >>> Instead of changing the name like this, which doesn't work for files,
> > >>> allowing duplicate measurements should be generic, based on policy.
> > >>
> > >> Perhaps it is just the end of the day and I'm a bit tired, but I just
> > >> read all of the above and I have no idea what your current thoughts
> > >> are regarding this patch.
> > > 
> > > Other than appending the timestamp, which is a hack, the patch is fine.
> > > Support for re-measuring an event can be upstreamed independently.
> > > 
> > 
> > Thanks for clarifying the details related to duplicate measurement 
> > detection and re-measuring.
> > 
> > I will keep the timestamp for the time being, even though its a hack, as 
> > it helps with re-measuring state changes in SELinux. We will add support 
> > for "policy driven" re-measurement as a subsequent patch series.
> 
> Once including the timestamp is upstreamed, removing it will be
> difficult, especially if different userspace applications are dependent
> on it.  Unless everyone is on board that removing the timestamp
> wouldn't be considered a regression, it cannot be upstreamed.

Feel free to just re-post just this one patch.  Otherwise the patch set
looks good.

thanks,

Mimi


^ permalink raw reply	[flat|nested] 28+ messages in thread

* Re: [PATCH v10 8/8] selinux: include a consumer of the new IMA critical data hook
  2021-01-14 16:44                     ` Mimi Zohar
  2021-01-14 16:50                       ` Mimi Zohar
@ 2021-01-14 16:51                       ` Paul Moore
  1 sibling, 0 replies; 28+ messages in thread
From: Paul Moore @ 2021-01-14 16:51 UTC (permalink / raw)
  To: Mimi Zohar
  Cc: Lakshmi Ramasubramanian, Sasha Levin, Tushar Sugandhi,
	Stephen Smalley, casey, agk, snitzer, gmazyland, tyhicks,
	James Morris, linux-integrity, selinux, linux-security-module,
	linux-kernel, dm-devel

On Thu, Jan 14, 2021 at 11:44 AM Mimi Zohar <zohar@linux.ibm.com> wrote:
>
> [Cc'ing Sasha]
>
> Hi Lakshmi,
>
> On Thu, 2021-01-14 at 08:22 -0800, Lakshmi Ramasubramanian wrote:
> > On 1/13/21 6:49 PM, Mimi Zohar wrote:
>
> > >>> Lakshmi is trying to address the situation where an event changes a
> > >>> value, but then is restored to the original value.  The original and
> > >>> subsequent events are measured, but restoring to the original value
> > >>> isn't re-measured.  This isn't any different than when a file is
> > >>> modified and then reverted.
> > >>>
> > >>> Instead of changing the name like this, which doesn't work for files,
> > >>> allowing duplicate measurements should be generic, based on policy.
> > >>
> > >> Perhaps it is just the end of the day and I'm a bit tired, but I just
> > >> read all of the above and I have no idea what your current thoughts
> > >> are regarding this patch.
> > >
> > > Other than appending the timestamp, which is a hack, the patch is fine.
> > > Support for re-measuring an event can be upstreamed independently.
> > >
> >
> > Thanks for clarifying the details related to duplicate measurement
> > detection and re-measuring.
> >
> > I will keep the timestamp for the time being, even though its a hack, as
> > it helps with re-measuring state changes in SELinux. We will add support
> > for "policy driven" re-measurement as a subsequent patch series.
>
> Once including the timestamp is upstreamed, removing it will be
> difficult, especially if different userspace applications are dependent
> on it.  Unless everyone is on board that removing the timestamp
> wouldn't be considered a regression, it cannot be upstreamed.

I'm not a fan of merging things which are known to be broken only with
the promise of fixing it later.  That goes double when the proper fix
will result in a user visible breaking change.

-- 
paul moore
www.paul-moore.com

^ permalink raw reply	[flat|nested] 28+ messages in thread

* Re: [PATCH v10 8/8] selinux: include a consumer of the new IMA critical data hook
  2021-01-14 16:50                       ` Mimi Zohar
@ 2021-01-14 17:48                         ` Lakshmi Ramasubramanian
  2021-01-14 19:21                           ` Lakshmi Ramasubramanian
  0 siblings, 1 reply; 28+ messages in thread
From: Lakshmi Ramasubramanian @ 2021-01-14 17:48 UTC (permalink / raw)
  To: Mimi Zohar, Paul Moore, Sasha Levin
  Cc: Tushar Sugandhi, Stephen Smalley, casey, agk, snitzer, gmazyland,
	tyhicks, James Morris, linux-integrity, selinux,
	linux-security-module, linux-kernel, dm-devel

On 1/14/21 8:50 AM, Mimi Zohar wrote:
> On Thu, 2021-01-14 at 11:44 -0500, Mimi Zohar wrote:
>> [Cc'ing Sasha]
>>
>> Hi Lakshmi,
>>
>> On Thu, 2021-01-14 at 08:22 -0800, Lakshmi Ramasubramanian wrote:
>>> On 1/13/21 6:49 PM, Mimi Zohar wrote:
>>
>>>>>> Lakshmi is trying to address the situation where an event changes a
>>>>>> value, but then is restored to the original value.  The original and
>>>>>> subsequent events are measured, but restoring to the original value
>>>>>> isn't re-measured.  This isn't any different than when a file is
>>>>>> modified and then reverted.
>>>>>>
>>>>>> Instead of changing the name like this, which doesn't work for files,
>>>>>> allowing duplicate measurements should be generic, based on policy.
>>>>>
>>>>> Perhaps it is just the end of the day and I'm a bit tired, but I just
>>>>> read all of the above and I have no idea what your current thoughts
>>>>> are regarding this patch.
>>>>
>>>> Other than appending the timestamp, which is a hack, the patch is fine.
>>>> Support for re-measuring an event can be upstreamed independently.
>>>>
>>>
>>> Thanks for clarifying the details related to duplicate measurement
>>> detection and re-measuring.
>>>
>>> I will keep the timestamp for the time being, even though its a hack, as
>>> it helps with re-measuring state changes in SELinux. We will add support
>>> for "policy driven" re-measurement as a subsequent patch series.
>>
>> Once including the timestamp is upstreamed, removing it will be
>> difficult, especially if different userspace applications are dependent
>> on it.  Unless everyone is on board that removing the timestamp
>> wouldn't be considered a regression, it cannot be upstreamed.
> 
> Feel free to just re-post just this one patch.  Otherwise the patch set
> looks good.
> 
> thanks,
> 

Sounds good Mimi - I will remove the timestamp and re-post the selinux 
patch.

thanks,
  -lakshmi



^ permalink raw reply	[flat|nested] 28+ messages in thread

* Re: [PATCH v10 5/8] IMA: limit critical data measurement based on a label
  2021-01-14  2:09   ` Mimi Zohar
@ 2021-01-14 17:57     ` Tushar Sugandhi
  0 siblings, 0 replies; 28+ messages in thread
From: Tushar Sugandhi @ 2021-01-14 17:57 UTC (permalink / raw)
  To: Mimi Zohar, stephen.smalley.work, casey, agk, snitzer, gmazyland, paul
  Cc: tyhicks, sashal, jmorris, nramas, linux-integrity, selinux,
	linux-security-module, linux-kernel, dm-devel



On 2021-01-13 6:09 p.m., Mimi Zohar wrote:
> On Thu, 2021-01-07 at 20:07 -0800, Tushar Sugandhi wrote:
>> Integrity critical data may belong to a single subsystem or it may
>> arise from cross subsystem interaction.  Currently there is no mechanism
>> to group or limit the data based on certain label.  Limiting and
>> grouping critical data based on a label would make it flexible and
>> configurable to measure.
>>
>> Define "label:=", a new IMA policy condition, for the IMA func
>> CRITICAL_DATA to allow grouping and limiting measurement of integrity
>> critical data.
>>
>> Limit the measurement to the labels that are specified in the IMA
>> policy - CRITICAL_DATA+"label:=".  If "label:=" is not provided with
>> the func CRITICAL_DATA, measure all the input integrity critical data.
>>
>> Signed-off-by: Tushar Sugandhi <tusharsu@linux.microsoft.com>
>> Reviewed-by: Tyler Hicks <tyhicks@linux.microsoft.com>
> 
> This is looking a lot better.
> 
> thanks,
> 
> Mimi
> 
Thanks a lot for the feedback Mimi.
Appreciate it. :)

~Tushar

^ permalink raw reply	[flat|nested] 28+ messages in thread

* Re: [PATCH v10 8/8] selinux: include a consumer of the new IMA critical data hook
  2021-01-14 17:48                         ` Lakshmi Ramasubramanian
@ 2021-01-14 19:21                           ` Lakshmi Ramasubramanian
  0 siblings, 0 replies; 28+ messages in thread
From: Lakshmi Ramasubramanian @ 2021-01-14 19:21 UTC (permalink / raw)
  To: Mimi Zohar, Paul Moore, Sasha Levin
  Cc: Tushar Sugandhi, Stephen Smalley, casey, agk, snitzer, gmazyland,
	tyhicks, James Morris, linux-integrity, selinux,
	linux-security-module, linux-kernel, dm-devel

On 1/14/21 9:48 AM, Lakshmi Ramasubramanian wrote:
> On 1/14/21 8:50 AM, Mimi Zohar wrote:
>> On Thu, 2021-01-14 at 11:44 -0500, Mimi Zohar wrote:
>>> [Cc'ing Sasha]
>>>
>>> Hi Lakshmi,
>>>
>>> On Thu, 2021-01-14 at 08:22 -0800, Lakshmi Ramasubramanian wrote:
>>>> On 1/13/21 6:49 PM, Mimi Zohar wrote:
>>>
>>>>>>> Lakshmi is trying to address the situation where an event changes a
>>>>>>> value, but then is restored to the original value.  The original and
>>>>>>> subsequent events are measured, but restoring to the original value
>>>>>>> isn't re-measured.  This isn't any different than when a file is
>>>>>>> modified and then reverted.
>>>>>>>
>>>>>>> Instead of changing the name like this, which doesn't work for 
>>>>>>> files,
>>>>>>> allowing duplicate measurements should be generic, based on policy.
>>>>>>
>>>>>> Perhaps it is just the end of the day and I'm a bit tired, but I just
>>>>>> read all of the above and I have no idea what your current thoughts
>>>>>> are regarding this patch.
>>>>>
>>>>> Other than appending the timestamp, which is a hack, the patch is 
>>>>> fine.
>>>>> Support for re-measuring an event can be upstreamed independently.
>>>>>
>>>>
>>>> Thanks for clarifying the details related to duplicate measurement
>>>> detection and re-measuring.
>>>>
>>>> I will keep the timestamp for the time being, even though its a 
>>>> hack, as
>>>> it helps with re-measuring state changes in SELinux. We will add 
>>>> support
>>>> for "policy driven" re-measurement as a subsequent patch series.
>>>
>>> Once including the timestamp is upstreamed, removing it will be
>>> difficult, especially if different userspace applications are dependent
>>> on it.  Unless everyone is on board that removing the timestamp
>>> wouldn't be considered a regression, it cannot be upstreamed.
>>
>> Feel free to just re-post just this one patch.  Otherwise the patch set
>> looks good.
>>
>> thanks,
>>
> 
> Sounds good Mimi - I will remove the timestamp and re-post the selinux 
> patch.
> 

I have removed the timestamp in the event name and have posted the 
selinux patch alone.

Thanks a lot for reviewing the changes.

  -lakshmi



^ permalink raw reply	[flat|nested] 28+ messages in thread

* Re: [PATCH v10 0/8] IMA: support for measuring kernel integrity critical data
  2021-01-08  4:07 [PATCH v10 0/8] IMA: support for measuring kernel integrity critical data Tushar Sugandhi
                   ` (7 preceding siblings ...)
  2021-01-08  4:07 ` [PATCH v10 8/8] selinux: include a consumer of the new IMA critical data hook Tushar Sugandhi
@ 2021-01-15 12:54 ` Mimi Zohar
  2021-01-15 17:26   ` Tushar Sugandhi
  8 siblings, 1 reply; 28+ messages in thread
From: Mimi Zohar @ 2021-01-15 12:54 UTC (permalink / raw)
  To: Tushar Sugandhi, stephen.smalley.work, casey, agk, snitzer,
	gmazyland, paul
  Cc: tyhicks, sashal, jmorris, nramas, linux-integrity, selinux,
	linux-security-module, linux-kernel, dm-devel

On Thu, 2021-01-07 at 20:07 -0800, Tushar Sugandhi wrote:
> IMA measures files and buffer data such as keys, command-line arguments
> passed to the kernel on kexec system call, etc.  While these measurements
> are necessary for monitoring and validating the integrity of the system,
> they are not sufficient.  Various data structures, policies, and states
> stored in kernel memory also impact the integrity of the system.
> Several kernel subsystems contain such integrity critical data -
> e.g.  LSMs like SELinux, AppArmor etc.  or device-mapper targets like
> dm-crypt, dm-verity, dm-integrity etc.  These kernel subsystems help
> protect the integrity of a system.  Their integrity critical data is not
> expected to change frequently during run-time.  Some of these structures
> cannot be defined as __ro_after_init, because they are initialized later.
> 
> For a given system, various external services/infrastructure tools
> (including the attestation service) interact with it - both during the
> setup and during rest of the system run-time.  They share sensitive data
> and/or execute critical workload on that system.  The external services
> may want to verify the current run-time state of the relevant kernel
> subsystems before fully trusting the system with business critical
> data/workload.  For instance, verifying that SELinux is in "enforce" mode
> along with the expected policy, disks are encrypted with a certain
> configuration, secure boot is enabled etc.
> 
> This series provides the necessary IMA functionality for kernel
> subsystems to ensure their configuration can be measured:
>   - by kernel subsystems themselves,
>   - in a tamper resistant way,
>   - and re-measured - triggered on state/configuration change.
> 
> This patch set:
>   - defines a new IMA hook ima_measure_critical_data() to measure
>     integrity critical data,
>   - limits the critical data being measured based on a label,
>   - defines a builtin critical data measurement policy,
>   - and includes an SELinux consumer of the new IMA critical data hook.

Thanks Tushar, Lakshmi.  This patch set is queued in the next-
integrity-testing branch.

Mimi


^ permalink raw reply	[flat|nested] 28+ messages in thread

* Re: [PATCH v10 0/8] IMA: support for measuring kernel integrity critical data
  2021-01-15 12:54 ` [PATCH v10 0/8] IMA: support for measuring kernel integrity critical data Mimi Zohar
@ 2021-01-15 17:26   ` Tushar Sugandhi
  0 siblings, 0 replies; 28+ messages in thread
From: Tushar Sugandhi @ 2021-01-15 17:26 UTC (permalink / raw)
  To: Mimi Zohar, stephen.smalley.work, casey, agk, snitzer, gmazyland, paul
  Cc: tyhicks, sashal, jmorris, nramas, linux-integrity, selinux,
	linux-security-module, linux-kernel, dm-devel



On 2021-01-15 4:54 a.m., Mimi Zohar wrote:
> On Thu, 2021-01-07 at 20:07 -0800, Tushar Sugandhi wrote:
>> IMA measures files and buffer data such as keys, command-line arguments
>> passed to the kernel on kexec system call, etc.  While these measurements
>> are necessary for monitoring and validating the integrity of the system,
>> they are not sufficient.  Various data structures, policies, and states
>> stored in kernel memory also impact the integrity of the system.
>> Several kernel subsystems contain such integrity critical data -
>> e.g.  LSMs like SELinux, AppArmor etc.  or device-mapper targets like
>> dm-crypt, dm-verity, dm-integrity etc.  These kernel subsystems help
>> protect the integrity of a system.  Their integrity critical data is not
>> expected to change frequently during run-time.  Some of these structures
>> cannot be defined as __ro_after_init, because they are initialized later.
>>
>> For a given system, various external services/infrastructure tools
>> (including the attestation service) interact with it - both during the
>> setup and during rest of the system run-time.  They share sensitive data
>> and/or execute critical workload on that system.  The external services
>> may want to verify the current run-time state of the relevant kernel
>> subsystems before fully trusting the system with business critical
>> data/workload.  For instance, verifying that SELinux is in "enforce" mode
>> along with the expected policy, disks are encrypted with a certain
>> configuration, secure boot is enabled etc.
>>
>> This series provides the necessary IMA functionality for kernel
>> subsystems to ensure their configuration can be measured:
>>    - by kernel subsystems themselves,
>>    - in a tamper resistant way,
>>    - and re-measured - triggered on state/configuration change.
>>
>> This patch set:
>>    - defines a new IMA hook ima_measure_critical_data() to measure
>>      integrity critical data,
>>    - limits the critical data being measured based on a label,
>>    - defines a builtin critical data measurement policy,
>>    - and includes an SELinux consumer of the new IMA critical data hook.
> 
> Thanks Tushar, Lakshmi.  This patch set is queued in the next-
> integrity-testing branch.
> 
> Mimi
> 
Hello Mimi, Paul, Stephen, Tyler,
Thanks a lot for reviewing this series and providing all the valuable 
feedback over the last few months.

We really really appreciate it.

Thanks,
Tushar

^ permalink raw reply	[flat|nested] 28+ messages in thread

end of thread, other threads:[~2021-01-15 17:27 UTC | newest]

Thread overview: 28+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2021-01-08  4:07 [PATCH v10 0/8] IMA: support for measuring kernel integrity critical data Tushar Sugandhi
2021-01-08  4:07 ` [PATCH v10 1/8] IMA: generalize keyring specific measurement constructs Tushar Sugandhi
2021-01-08  4:07 ` [PATCH v10 2/8] IMA: add support to measure buffer data hash Tushar Sugandhi
2021-01-08  4:07 ` [PATCH v10 3/8] IMA: define a hook to measure kernel integrity critical data Tushar Sugandhi
2021-01-08  4:07 ` [PATCH v10 4/8] IMA: add policy rule to measure " Tushar Sugandhi
2021-01-08  4:07 ` [PATCH v10 5/8] IMA: limit critical data measurement based on a label Tushar Sugandhi
2021-01-14  2:09   ` Mimi Zohar
2021-01-14 17:57     ` Tushar Sugandhi
2021-01-08  4:07 ` [PATCH v10 6/8] IMA: extend critical data hook to limit the " Tushar Sugandhi
2021-01-08  4:07 ` [PATCH v10 7/8] IMA: define a builtin critical data measurement policy Tushar Sugandhi
2021-01-08  4:07 ` [PATCH v10 8/8] selinux: include a consumer of the new IMA critical data hook Tushar Sugandhi
2021-01-12 16:27   ` Paul Moore
2021-01-12 18:25     ` Lakshmi Ramasubramanian
2021-01-13 19:13     ` Mimi Zohar
2021-01-13 19:19       ` Paul Moore
2021-01-13 21:11         ` Mimi Zohar
2021-01-13 22:10           ` Paul Moore
2021-01-13 23:10             ` Mimi Zohar
2021-01-14  2:40               ` Paul Moore
2021-01-14  2:49                 ` Mimi Zohar
2021-01-14 16:22                   ` Lakshmi Ramasubramanian
2021-01-14 16:44                     ` Mimi Zohar
2021-01-14 16:50                       ` Mimi Zohar
2021-01-14 17:48                         ` Lakshmi Ramasubramanian
2021-01-14 19:21                           ` Lakshmi Ramasubramanian
2021-01-14 16:51                       ` Paul Moore
2021-01-15 12:54 ` [PATCH v10 0/8] IMA: support for measuring kernel integrity critical data Mimi Zohar
2021-01-15 17:26   ` Tushar Sugandhi

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).