Kernel integrity critical data can be defined as the in-memory kernel
data which if accidentally or maliciously altered, can compromise the
integrity of the system.
There are several kernel subsystems that contain integrity critical
data - e.g. LSMs like SELinux, or AppArmor; or device-mapper targets
like dm-crypt, dm-verity etc. Examples of critical data could be kernel
in-memory r/o structures, hash of the memory structures, or data that
represents a linux kernel subsystem state.
This patch set defines a new IMA hook namely ima_measure_critical_data()
to measure the critical data. Kernel subsystems can use this
functionality, to take advantage of IMA's measuring and quoting
abilities - thus ultimately enabling remote attestation for the
subsystem specific information stored in the kernel memory.
The functionality is generic enough to measure the data, from the kernel
subsystems, that is required to protect the integrity of the kernel at
runtime.
System administrators may want to limit the critical data being
measured, quoted, and attested. To enable that, a new IMA policy
condition is defined.
This patch set also addresses the need for measuring kernel critical
data early, before a custom IMA policy is loaded - by providing a
builtin IMA policy.
And lastly, the series provides the first consumer of the new IMA hook -
namely SeLinux.
This series is based on the following repo/branch:
repo: https://github.com/torvalds/linux
branch: master
commit 09162bc32c88 ("Linux 5.10-rc4")
This series also has a dependency on the following patch
https://patchwork.kernel.org/patch/11901423/
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: add a built-in policy rule for critical data measurement
selinux: measure state and hash of the policy using IMA
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: extend policy to add data sources as a critical data measurement
constraint
IMA: add support to critical data hook to limit data sources for
measurement
Documentation/ABI/testing/ima_policy | 10 +-
include/linux/ima.h | 8 +
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 | 81 +++++++++-
security/integrity/ima/ima_policy.c | 123 ++++++++++++---
security/integrity/ima/ima_queue_keys.c | 3 +-
security/selinux/Makefile | 2 +
security/selinux/hooks.c | 3 +
security/selinux/include/security.h | 11 +-
security/selinux/measure.c | 157 +++++++++++++++++++
security/selinux/selinuxfs.c | 8 +
security/selinux/ss/services.c | 71 +++++++--
15 files changed, 448 insertions(+), 49 deletions(-)
create mode 100644 security/selinux/measure.c
--
2.17.1
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, through the
IMA policy.
Extend the IMA hook ima_measure_critical_data() to support passing
the data source name as an input parameter, so that the policy rule can
be used to limit data sources being measured.
Signed-off-by: Tushar Sugandhi <[email protected]>
---
include/linux/ima.h | 6 ++++--
security/integrity/ima/ima_main.c | 11 ++++++++---
2 files changed, 12 insertions(+), 5 deletions(-)
diff --git a/include/linux/ima.h b/include/linux/ima.h
index 9911a6e496b6..60ba073f1575 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_data_source,
+ const char *event_name,
const void *buf, int buf_len,
bool measure_buf_hash);
@@ -119,7 +120,8 @@ 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_data_source,
+ const char *event_name,
const void *buf, int buf_len,
bool measure_buf_hash) {}
#endif /* CONFIG_IMA */
diff --git a/security/integrity/ima/ima_main.c b/security/integrity/ima/ima_main.c
index 7661f09569f3..27b8b8316622 100644
--- a/security/integrity/ima/ima_main.c
+++ b/security/integrity/ima/ima_main.c
@@ -924,6 +924,7 @@ void ima_kexec_cmdline(int kernel_fd, const void *buf, int size)
/**
* ima_measure_critical_data - measure kernel integrity critical data
+ * @event_data_source: kernel data source being measured
* @event_name: event name to be used for the buffer entry
* @buf: pointer to buffer containing data to measure
* @buf_len: length of buffer(in bytes)
@@ -932,6 +933,9 @@ void ima_kexec_cmdline(int kernel_fd, const void *buf, int size)
* Measure the kernel subsystem data, critical to the integrity of the kernel,
* into the IMA log and extend the @pcr.
*
+ * Use @event_data_source to describe the kernel data source for the buffer
+ * being measured.
+ *
* Use @event_name to describe the state/buffer data change.
* Examples of critical data (buf) could be kernel in-memory r/o structures,
* hash of the memory structures, or data that represents subsystem state
@@ -944,17 +948,18 @@ void ima_kexec_cmdline(int kernel_fd, const void *buf, int size)
*
* The data (buf) can only be measured, not appraised.
*/
-void ima_measure_critical_data(const char *event_name,
+void ima_measure_critical_data(const char *event_data_source,
+ const char *event_name,
const void *buf, int buf_len,
bool measure_buf_hash)
{
- if (!event_name || !buf || !buf_len) {
+ if (!event_name || !event_data_source || !buf || !buf_len) {
pr_err("Invalid arguments passed to %s().\n", __func__);
return;
}
process_buffer_measurement(NULL, buf, buf_len, event_name,
- CRITICAL_DATA, 0, NULL,
+ CRITICAL_DATA, 0, event_data_source,
measure_buf_hash);
}
--
2.17.1
IMA provides capabilities to measure file data, and in-memory buffer
data. However, currently, IMA does not provide a generic function for
kernel subsystems to measure the integrity critical data. Kernel
integrity critical data can be defined as the in-memory kernel data which
if accidentally or maliciously altered, can compromise the integrity of
the system. Examples of critical data would be kernel in-memory r/o
structures, hash of the memory structures, or data that represents a
linux kernel subsystem state change.
Define a new IMA hook named ima_measure_critical_data to measure kernel
integrity critical data.
Signed-off-by: Tushar Sugandhi <[email protected]>
---
Documentation/ABI/testing/ima_policy | 2 +-
include/linux/ima.h | 6 +++++
security/integrity/ima/ima.h | 1 +
security/integrity/ima/ima_api.c | 2 +-
security/integrity/ima/ima_main.c | 36 ++++++++++++++++++++++++++++
security/integrity/ima/ima_policy.c | 2 ++
6 files changed, 47 insertions(+), 2 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/include/linux/ima.h b/include/linux/ima.h
index 8fa7bcfb2da2..9911a6e496b6 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, int buf_len,
+ bool measure_buf_hash);
#ifdef CONFIG_IMA_KEXEC
extern void ima_add_kexec_buffer(struct kimage *image);
@@ -116,6 +119,9 @@ 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, int buf_len,
+ bool measure_buf_hash) {}
#endif /* CONFIG_IMA */
#ifndef CONFIG_IMA_KEXEC
diff --git a/security/integrity/ima/ima.h b/security/integrity/ima/ima.h
index fa3044a7539f..7d9deda6a8b3 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 af218babd198..9917e1730cb6 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 f3501bdd1035..7661f09569f3 100644
--- a/security/integrity/ima/ima_main.c
+++ b/security/integrity/ima/ima_main.c
@@ -922,6 +922,42 @@ 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 to be used for the buffer entry
+ * @buf: pointer to buffer containing data to measure
+ * @buf_len: length of buffer(in bytes)
+ * @measure_buf_hash: measure buffer hash
+ *
+ * Measure the kernel subsystem data, critical to the integrity of the kernel,
+ * into the IMA log and extend the @pcr.
+ *
+ * Use @event_name to describe the state/buffer data change.
+ * Examples of critical data (buf) could be kernel in-memory r/o structures,
+ * hash of the memory structures, or data that represents subsystem state
+ * change.
+ *
+ * If @measure_buf_hash is set to true - measure hash of the buffer data,
+ * else measure the buffer data itself.
+ * measure_buf_hash can be used to save space, if the data being measured
+ * is too large.
+ *
+ * The data (buf) can only be measured, not appraised.
+ */
+void ima_measure_critical_data(const char *event_name,
+ const void *buf, int buf_len,
+ bool measure_buf_hash)
+{
+ if (!event_name || !buf || !buf_len) {
+ pr_err("Invalid arguments passed to %s().\n", __func__);
+ return;
+ }
+
+ process_buffer_measurement(NULL, buf, buf_len, event_name,
+ CRITICAL_DATA, 0, NULL,
+ measure_buf_hash);
+}
+
static int __init init_ima(void)
{
int error;
diff --git a/security/integrity/ima/ima_policy.c b/security/integrity/ima/ima_policy.c
index 25419c7ff50b..2a0c0603626e 100644
--- a/security/integrity/ima/ima_policy.c
+++ b/security/integrity/ima/ima_policy.c
@@ -1251,6 +1251,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
From: Lakshmi Ramasubramanian <[email protected]>
The IMA hook to measure kernel critical data, namely
ima_measure_critical_data(), could be called before a custom IMA policy
is loaded. Define a new critical data builtin policy to allow measuring
early kernel integrity critical data before a custom IMA policy is
loaded.
Add critical data to built-in IMA rules if the kernel command line
contains "ima_policy=critical_data".
Signed-off-by: Lakshmi Ramasubramanian <[email protected]>
---
security/integrity/ima/ima_policy.c | 12 ++++++++++++
1 file changed, 12 insertions(+)
diff --git a/security/integrity/ima/ima_policy.c b/security/integrity/ima/ima_policy.c
index c9e52dab0638..119604a3efa0 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 __ro_after_init;
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
@@ -875,6 +882,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
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
the hash of the buffer data.
Measuring in-memory buffer-data/buffer-data-hash is different than
measuring file-data/file-data-hash. For the file, IMA stores the
measurements in both measurement log and the file's extended attribute -
which can later be used for appraisal as well. For buffer, the
measurements are only stored in the IMA log, since the buffer has no
extended attributes associated with it.
Introduce a boolean parameter measure_buf_hash to support measuring
hash of a buffer, which would be much smaller, instead of the buffer
itself.
Signed-off-by: Tushar Sugandhi <[email protected]>
---
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 | 36 +++++++++++++++++---
security/integrity/ima/ima_queue_keys.c | 3 +-
5 files changed, 38 insertions(+), 8 deletions(-)
diff --git a/security/integrity/ima/ima.h b/security/integrity/ima/ima.h
index e5622ce8cbb1..fa3044a7539f 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 measure_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 3dd8c2e4314e..be64c0bf62a7 100644
--- a/security/integrity/ima/ima_appraise.c
+++ b/security/integrity/ima/ima_appraise.c
@@ -347,7 +347,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 2691ce894189..f3501bdd1035 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,23 @@ int ima_post_load_data(char *buf, loff_t size,
* @func: IMA hook
* @pcr: pcr to extend the measurement
* @func_data: private data specific to @func, can be NULL.
+ * @measure_buf_hash: measure buffer hash
*
- * Based on policy, the buffer is measured into the ima log.
+ * Measure the buffer into the IMA log, and extend the @pcr.
+ *
+ * Determine what buffers are allowed to be measured, based on the policy rules
+ * and the IMA hook passed using @func.
+ *
+ * Use @func_data, if provided, to match against the measurement policy rule
+ * data for @func.
+ *
+ * If @measure_buf_hash is set to true - measure hash of the buffer data,
+ * else measure the buffer data itself.
*/
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 measure_buf_hash)
{
int ret = 0;
const char *audit_cause = "ENOMEM";
@@ -807,6 +818,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 buf_hash[IMA_MAX_DIGEST_SIZE];
+ int buf_hash_len = hash_digest_size[ima_hash_algo];
int violation = 0;
int action = 0;
u32 secid;
@@ -849,6 +862,20 @@ void process_buffer_measurement(struct inode *inode, const void *buf, int size,
goto out;
}
+ if (measure_buf_hash) {
+ memcpy(buf_hash, hash.hdr.digest, buf_hash_len);
+
+ ret = ima_calc_buffer_hash(buf_hash, buf_hash_len,
+ iint.ima_hash);
+ if (ret < 0) {
+ audit_cause = "measure_buf_hash_error";
+ goto out;
+ }
+
+ event_data.buf = buf_hash;
+ event_data.buf_len = buf_hash_len;
+ }
+
ret = ima_alloc_init_template(&event_data, &entry, template);
if (ret < 0) {
audit_cause = "alloc_entry";
@@ -890,7 +917,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
System administrators should be able to limit which kernel subsystems
they want to measure the critical data for. To enable that, an IMA policy
condition to choose specific kernel subsystems is needed. This policy
condition would constrain the measurement of the critical data to the
given kernel subsystems.
Add a new IMA policy condition - "data_sources:=" to the IMA func
CRITICAL_DATA to allow measurement of various kernel subsystems. This
policy condition would enable the system administrators to restrict the
measurement to the subsystems listed in "data_sources:=".
Limit the measurement to the subsystems that are specified in the IMA
policy - CRITICAL_DATA+"data_sources:=". If "data_sources:=" is not
provided with the func CRITICAL_DATA, the data from all the
supported kernel subsystems is measured.
Signed-off-by: Tushar Sugandhi <[email protected]>
---
Documentation/ABI/testing/ima_policy | 4 ++++
security/integrity/ima/ima_policy.c | 27 ++++++++++++++++++++++++++-
2 files changed, 30 insertions(+), 1 deletion(-)
diff --git a/Documentation/ABI/testing/ima_policy b/Documentation/ABI/testing/ima_policy
index 6ec7daa87cba..ee60442a41cd 100644
--- a/Documentation/ABI/testing/ima_policy
+++ b/Documentation/ABI/testing/ima_policy
@@ -52,6 +52,10 @@ Description:
template:= name of a defined IMA template type
(eg, ima-ng). Only valid when action is "measure".
pcr:= decimal value
+ data_sources:= list of kernel subsystems that contain
+ kernel in-memory data critical to the integrity of the kernel.
+ Only valid when action is "measure" and func is
+ CRITICAL_DATA.
default policy:
# PROC_SUPER_MAGIC
diff --git a/security/integrity/ima/ima_policy.c b/security/integrity/ima/ima_policy.c
index 583be7674f3e..c9e52dab0638 100644
--- a/security/integrity/ima/ima_policy.c
+++ b/security/integrity/ima/ima_policy.c
@@ -934,7 +934,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_data_sources, Opt_err
};
static const match_table_t policy_tokens = {
@@ -971,6 +971,7 @@ static const match_table_t policy_tokens = {
{Opt_pcr, "pcr=%s"},
{Opt_template, "template=%s"},
{Opt_keyrings, "keyrings=%s"},
+ {Opt_data_sources, "data_sources=%s"},
{Opt_err, NULL}
};
@@ -1350,6 +1351,24 @@ static int ima_parse_rule(char *rule, struct ima_rule_entry *entry)
entry->flags |= IMA_KEYRINGS;
break;
+ case Opt_data_sources:
+ ima_log_string(ab, "data_sources",
+ args[0].from);
+
+ if (entry->data_sources) {
+ result = -EINVAL;
+ break;
+ }
+
+ entry->data_sources = ima_alloc_rule_opt_list(args);
+ if (IS_ERR(entry->data_sources)) {
+ result = PTR_ERR(entry->data_sources);
+ entry->data_sources = NULL;
+ break;
+ }
+
+ entry->flags |= IMA_DATA_SOURCES;
+ break;
case Opt_fsuuid:
ima_log_string(ab, "fsuuid", args[0].from);
@@ -1730,6 +1749,12 @@ int ima_policy_show(struct seq_file *m, void *v)
seq_puts(m, " ");
}
+ if (entry->flags & IMA_DATA_SOURCES) {
+ seq_puts(m, "data_sources=");
+ ima_show_rule_opt_list(m, entry->data_sources);
+ 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
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 a policy rule to define the constraints for restricting integrity
critical data measurements.
Signed-off-by: Tushar Sugandhi <[email protected]>
---
security/integrity/ima/ima_policy.c | 35 +++++++++++++++++++++++++----
1 file changed, 31 insertions(+), 4 deletions(-)
diff --git a/security/integrity/ima/ima_policy.c b/security/integrity/ima/ima_policy.c
index 2a0c0603626e..583be7674f3e 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_DATA_SOURCES 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 *data_sources; /* Measure data from these sources */
struct ima_template_desc *template;
};
@@ -479,6 +481,12 @@ static bool ima_match_rule_data(struct ima_rule_entry *rule,
else
opt_list = rule->keyrings;
break;
+ case CRITICAL_DATA:
+ if (!rule->data_sources)
+ return true;
+ else
+ opt_list = rule->data_sources;
+ break;
default:
break;
}
@@ -518,13 +526,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;
@@ -1119,6 +1133,19 @@ 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_DATA_SOURCES) ||
+ (entry->flags & ~(IMA_FUNC | IMA_UID | IMA_PCR |
+ IMA_DATA_SOURCES)))
+ return false;
+
+ if (ima_rule_contains_lsm_cond(entry))
+ return false;
+
break;
default:
return false;
--
2.17.1
From: Lakshmi Ramasubramanian <[email protected]>
IMA measures files and buffer data such as keys, command line arguments
passed to the kernel on kexec system call, etc. While these measurements
enable monitoring and validating the integrity of the system, it is not
sufficient. In-memory data structures maintained by various kernel
components store the current state and policies configured for
the components. Updates to these data structures would have an impact on
the functionalities. For example, the in-memory data structures
maintained by SELinux store the configuration and policies for this
security module and thereby determine the security functionalities
provided by this module. Changes to these data at runtime would have
an impact on the security guarantees provided by SELinux. Measuring
such in-memory data structures through IMA subsystem provides a secure
way for a remote attestation service to know the state of the system
and also the runtime changes in the state of the system.
SELinux configuration and policy are some of the critical data for this
security module that need to be measured. This measurement can be used
by an attestation service, for instance, to verify if the configurations
and policies have been setup correctly and that they haven't been
tampered at run-time.
Measure SELinux configurations, policy capabilities settings, and
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.
Add "selinux" to the list of supported data sources maintained by IMA
to enable measuring SELinux data.
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 data_sources=selinux template=ima-buf
Sample measurement of SELinux state and hash of the policy:
10 e32e...5ac3 ima-buf sha256:86e8...4594 selinux-state-1595389364:287899386 696e697469616c697a65643d313b656e61626c65643d313b656e666f7263696e673d303b636865636b72657170726f743d313b6e6574776f726b5f706565725f636f6e74726f6c733d313b6f70656e5f7065726d733d313b657874656e6465645f736f636b65745f636c6173733d313b616c776179735f636865636b5f6e6574776f726b3d303b6367726f75705f7365636c6162656c3d313b6e6e705f6e6f737569645f7472616e736974696f6e3d313b67656e66735f7365636c6162656c5f73796d6c696e6b733d303
10 9e81...0857 ima-buf sha256:4941...68fc selinux-policy-hash-1597335667:462051628 8d1d...1834
To verify the measurement check the following:
Execute the following command to extract the measured data
from the IMA log for SELinux configuration (selinux-state).
grep "selinux-state" /sys/kernel/security/integrity/ima/ascii_runtime_measurements | tail -1 | cut -d' ' -f 6 | xxd -r -p
The output should be the list of key-value pairs. For example,
initialized=1;enabled=1;enforcing=0;checkreqprot=1;network_peer_controls=1;open_perms=1;extended_socket_class=1;always_check_network=0;cgroup_seclabel=1;nnp_nosuid_transition=1;genfs_seclabel_symlinks=0;
To verify the measured data with the current SELinux state:
=> enabled should be set to 1 if /sys/fs/selinux folder exists,
0 otherwise
For other entries, compare the integer value in the files
=> /sys/fs/selinux/enforce
=> /sys/fs/selinux/checkreqprot
And, each of the policy capabilities files under
=> /sys/fs/selinux/policy_capabilities
Note that the actual verification would be against an expected state
and done on a system other than the measured system, typically
requiring "initialized=1; enabled=1;enforcing=1;checkreqprot=0;" for
a secure state and then whatever policy capabilities are actually set
in the expected policy (which can be extracted from the policy itself
via seinfo, for example).
For selinux-policy-hash, the hash of SELinux policy is included
in the IMA log entry.
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 <[email protected]>
Suggested-by: Stephen Smalley <[email protected]>
---
Documentation/ABI/testing/ima_policy | 6 +-
security/selinux/Makefile | 2 +
security/selinux/hooks.c | 3 +
security/selinux/include/security.h | 11 +-
security/selinux/measure.c | 157 +++++++++++++++++++++++++++
security/selinux/selinuxfs.c | 8 ++
security/selinux/ss/services.c | 71 ++++++++++--
7 files changed, 247 insertions(+), 11 deletions(-)
create mode 100644 security/selinux/measure.c
diff --git a/Documentation/ABI/testing/ima_policy b/Documentation/ABI/testing/ima_policy
index ee60442a41cd..db1ee7bcdba7 100644
--- a/Documentation/ABI/testing/ima_policy
+++ b/Documentation/ABI/testing/ima_policy
@@ -52,7 +52,7 @@ Description:
template:= name of a defined IMA template type
(eg, ima-ng). Only valid when action is "measure".
pcr:= decimal value
- data_sources:= list of kernel subsystems that contain
+ data_sources:= list of kernel subsystems (eg, SeLinux) that contain
kernel in-memory data critical to the integrity of the kernel.
Only valid when action is "measure" and func is
CRITICAL_DATA.
@@ -135,3 +135,7 @@ Description:
keys added to .builtin_trusted_keys or .ima keyring:
measure func=KEY_CHECK keyrings=.builtin_trusted_keys|.ima
+
+ Example of measure rule using CRITICAL_DATA to measure critical data
+
+ measure func=CRITICAL_DATA data_sources=selinux
diff --git a/security/selinux/Makefile b/security/selinux/Makefile
index 4d8e0e8adf0b..83d512116341 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) += measure.o
+
ccflags-y := -I$(srctree)/security/selinux -I$(srctree)/security/selinux/include
$(addprefix $(obj)/,$(selinux-y)): $(obj)/flask.h
diff --git a/security/selinux/hooks.c b/security/selinux/hooks.c
index 6b1826fc3658..8b9fde47ae28 100644
--- a/security/selinux/hooks.c
+++ b/security/selinux/hooks.c
@@ -7398,6 +7398,9 @@ int selinux_disable(struct selinux_state *state)
}
selinux_mark_disabled(state);
+ mutex_lock(&state->policy_mutex);
+ selinux_measure_state(state);
+ mutex_unlock(&state->policy_mutex);
pr_info("SELinux: Disabled at runtime.\n");
diff --git a/security/selinux/include/security.h b/security/selinux/include/security.h
index 3cc8bab31ea8..18ee65c98446 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_policy_kernel(struct selinux_state *state,
+ void **data, size_t *len);
int security_policycap_supported(struct selinux_state *state,
unsigned int req_cap);
@@ -446,4 +447,12 @@ extern void ebitmap_cache_init(void);
extern void hashtab_cache_init(void);
extern int security_sidtab_hash_stats(struct selinux_state *state, char *page);
+#ifdef CONFIG_IMA
+extern void selinux_measure_state(struct selinux_state *selinux_state);
+#else
+static inline void selinux_measure_state(struct selinux_state *selinux_state)
+{
+}
+#endif
+
#endif /* _SELINUX_SECURITY_H_ */
diff --git a/security/selinux/measure.c b/security/selinux/measure.c
new file mode 100644
index 000000000000..65d42059f588
--- /dev/null
+++ b/security/selinux/measure.c
@@ -0,0 +1,157 @@
+// SPDX-License-Identifier: GPL-2.0-or-later
+/*
+ * Measure SELinux state using IMA subsystem.
+ */
+#include <linux/vmalloc.h>
+#include <linux/ktime.h>
+#include <linux/ima.h>
+#include "security.h"
+
+/*
+ * This function creates a unique name by appending the timestamp to
+ * the given string. This string is passed as "event_name" to the IMA
+ * hook to measure the given SELinux data.
+ *
+ * The data provided by SELinux to the IMA subsystem for measuring may have
+ * already been measured (for instance the same state existed earlier).
+ * But for SELinux the current data represents a state change and hence
+ * needs to be measured again. To enable this, pass a unique "event_name"
+ * to the IMA hook so that IMA subsystem will always measure the given data.
+ *
+ * For example,
+ * At time T0 SELinux data to be measured is "foo". IMA measures it.
+ * At time T1 the data is changed to "bar". IMA measures it.
+ * At time T2 the data is changed to "foo" again. IMA will not measure it
+ * (since it was already measured) unless the event_name, for instance,
+ * is different in this call.
+ */
+static char *selinux_event_name(const char *name_prefix)
+{
+ char *event_name = NULL;
+ struct timespec64 cur_time;
+
+ ktime_get_real_ts64(&cur_time);
+ event_name = kasprintf(GFP_KERNEL, "%s-%lld:%09ld", name_prefix,
+ cur_time.tv_sec, cur_time.tv_nsec);
+ if (!event_name) {
+ pr_err("%s: event name not allocated.\n", __func__);
+ return NULL;
+ }
+
+ return event_name;
+}
+
+static int read_selinux_state(char **state_str, int *state_str_len,
+ struct selinux_state *state)
+{
+ char *buf, *str_fmt = "%s=%d;";
+ int i, buf_len, curr;
+ bool initialized = selinux_initialized(state);
+ bool enabled = !selinux_disabled(state);
+ bool enforcing = enforcing_enabled(state);
+ bool checkreqprot = checkreqprot_get(state);
+
+ buf_len = snprintf(NULL, 0, str_fmt, "initialized", initialized);
+ buf_len += snprintf(NULL, 0, str_fmt, "enabled", enabled);
+ buf_len += snprintf(NULL, 0, str_fmt, "enforcing", enforcing);
+ buf_len += snprintf(NULL, 0, str_fmt, "checkreqprot", checkreqprot);
+
+ for (i = 0; i < __POLICYDB_CAPABILITY_MAX; i++) {
+ buf_len += snprintf(NULL, 0, str_fmt,
+ selinux_policycap_names[i],
+ state->policycap[i]);
+ }
+ ++buf_len;
+
+ buf = kzalloc(buf_len, GFP_KERNEL);
+ if (!buf)
+ return -ENOMEM;
+
+ curr = scnprintf(buf, buf_len, str_fmt,
+ "initialized", initialized);
+ curr += scnprintf((buf + curr), (buf_len - curr), str_fmt,
+ "enabled", enabled);
+ curr += scnprintf((buf + curr), (buf_len - curr), str_fmt,
+ "enforcing", enforcing);
+ curr += scnprintf((buf + curr), (buf_len - curr), str_fmt,
+ "checkreqprot", checkreqprot);
+
+ for (i = 0; i < __POLICYDB_CAPABILITY_MAX; i++) {
+ curr += scnprintf((buf + curr), (buf_len - curr), str_fmt,
+ selinux_policycap_names[i],
+ state->policycap[i]);
+ }
+
+ *state_str = buf;
+ *state_str_len = curr;
+
+ return 0;
+}
+
+/*
+ * selinux_measure_state - Measure SELinux state configuration and hash of
+ * the SELinux policy.
+ * @state: selinux state struct
+ *
+ * NOTE: This function must be called with policy_mutex held.
+ */
+void selinux_measure_state(struct selinux_state *state)
+{
+ void *policy = NULL;
+ char *state_event_name = NULL;
+ char *policy_event_name = NULL;
+ char *state_str = NULL;
+ size_t policy_len;
+ int state_str_len, rc = 0;
+ bool initialized = selinux_initialized(state);
+
+ /*
+ * Get a unique string for measuring the current SELinux state.
+ */
+ state_event_name = selinux_event_name("selinux-state");
+ if (!state_event_name) {
+ pr_err("%s: Event name for state not allocated.\n",
+ __func__);
+ rc = -ENOMEM;
+ goto out;
+ }
+
+ rc = read_selinux_state(&state_str, &state_str_len, state);
+ if (rc) {
+ pr_err("%s: Failed to read state %d.\n", __func__, rc);
+ goto out;
+ }
+
+ ima_measure_critical_data("selinux", state_event_name,
+ state_str, state_str_len, false);
+
+ /*
+ * Measure SELinux policy only after initialization is completed.
+ */
+ if (!initialized)
+ goto out;
+
+ policy_event_name = selinux_event_name("selinux-policy-hash");
+ if (!policy_event_name) {
+ pr_err("%s: Event name for policy not allocated.\n",
+ __func__);
+ rc = -ENOMEM;
+ goto out;
+ }
+
+ rc = security_read_policy_kernel(state, &policy, &policy_len);
+ if (rc) {
+ pr_err("%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);
+ kfree(state_str);
+ kfree(state_event_name);
+}
diff --git a/security/selinux/selinuxfs.c b/security/selinux/selinuxfs.c
index 4bde570d56a2..015650220cb2 100644
--- a/security/selinux/selinuxfs.c
+++ b/security/selinux/selinuxfs.c
@@ -182,6 +182,10 @@ static ssize_t sel_write_enforce(struct file *file, const char __user *buf,
selinux_status_update_setenforce(state, new_value);
if (!new_value)
call_blocking_lsm_notifier(LSM_POLICY_CHANGE, NULL);
+
+ mutex_lock(&state->policy_mutex);
+ selinux_measure_state(state);
+ mutex_unlock(&state->policy_mutex);
}
length = count;
out:
@@ -762,6 +766,10 @@ static ssize_t sel_write_checkreqprot(struct file *file, const char __user *buf,
checkreqprot_set(fsi->state, (new_value ? 1 : 0));
length = count;
+
+ mutex_lock(&fsi->state->policy_mutex);
+ selinux_measure_state(fsi->state);
+ mutex_unlock(&fsi->state->policy_mutex);
out:
kfree(page);
return length;
diff --git a/security/selinux/ss/services.c b/security/selinux/ss/services.c
index 9704c8a32303..dfa2e00894ae 100644
--- a/security/selinux/ss/services.c
+++ b/security/selinux/ss/services.c
@@ -2180,6 +2180,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_measure_state(state);
}
void selinux_policy_commit(struct selinux_state *state,
@@ -3875,8 +3876,33 @@ int security_netlbl_sid_to_secattr(struct selinux_state *state,
}
#endif /* CONFIG_NETLABEL */
+/**
+ * security_read_selinux_policy - read the policy.
+ * @policy: SELinux policy
+ * @data: binary policy data
+ * @len: length of data in bytes
+ *
+ */
+static int security_read_selinux_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 +3911,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 +3922,43 @@ int security_read_policy(struct selinux_state *state,
if (!*data)
return -ENOMEM;
- fp.data = *data;
- fp.len = *len;
+ return security_read_selinux_policy(policy, *data, len);
+}
- rc = policydb_write(&policy->policydb, &fp);
- if (rc)
- return rc;
+/**
+ * security_read_policy_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_policy_kernel(struct selinux_state *state,
+ void **data, size_t *len)
+{
+ struct selinux_policy *policy;
+ int rc = 0;
- *len = (unsigned long)fp.data - (unsigned long)*data;
- return 0;
+ policy = rcu_dereference_protected(
+ state->policy, lockdep_is_held(&state->policy_mutex));
+ if (!policy) {
+ rc = -EINVAL;
+ goto out;
+ }
+
+ *len = policy->policydb.len;
+ *data = vmalloc(*len);
+ if (!*data) {
+ rc = -ENOMEM;
+ goto out;
+ }
+ rc = security_read_selinux_policy(policy, *data, len);
+
+out:
+ return rc;
}
--
2.17.1
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 <[email protected]>
---
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 | 49 ++++++++++++++++++-----------
4 files changed, 40 insertions(+), 27 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..af218babd198 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: private data specific to @func, can 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 bc8c9fdb20a8..2691ce894189 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: private data specific to @func, can 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..25419c7ff50b 100644
--- a/security/integrity/ima/ima_policy.c
+++ b/security/integrity/ima/ima_policy.c
@@ -453,30 +453,44 @@ int ima_lsm_policy_change(struct notifier_block *nb, unsigned long event,
}
/**
- * ima_match_keyring - determine whether the keyring matches the measure rule
- * @rule: a pointer to a rule
- * @keyring: name of the keyring to match against the measure rule
+ * ima_match_rule_data - determine whether the given func_data matches
+ * the measure rule data
+ * @rule: IMA policy 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;
+ else
+ opt_list = rule->keyrings;
+ break;
+ default:
+ break;
+ }
- if (!keyring)
+ if (!func_data)
+ return false;
+
+ if (!opt_list)
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 +507,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: private data specific to @func, can 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 +624,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: private data specific to @func, can be NULL.
*
* Measure decision based on func/mask/fsmagic and LSM(subj/obj/type)
* conditions.
@@ -623,7 +636,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 +651,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
On Thu 2020-11-19 15:26:03, Tushar Sugandhi wrote:
> Kernel integrity critical data can be defined as the in-memory kernel
> data which if accidentally or maliciously altered, can compromise the
> integrity of the system.
Is that an useful definition?
> There are several kernel subsystems that contain integrity critical
> data - e.g. LSMs like SELinux, or AppArmor; or device-mapper targets
> like dm-crypt, dm-verity etc. Examples of critical data could be kernel
> in-memory r/o structures, hash of the memory structures, or data that
> represents a linux kernel subsystem state.
>
> This patch set defines a new IMA hook namely ima_measure_critical_data()
> to measure the critical data. Kernel subsystems can use this
> functionality, to take advantage of IMA's measuring and quoting
> abilities - thus ultimately enabling remote attestation for the
> subsystem specific information stored in the kernel memory.
How is it supposed to be useful?
I'm pretty sure there are critical data that are not measured by
proposed module... and that are written under normal circumstances.
Best regards,
Pavel
--
http://www.livejournal.com/~pavelmachek
Hi Lakshmi,
On Thu, 2020-11-19 at 15:26 -0800, Tushar Sugandhi wrote:
> From: Lakshmi Ramasubramanian <[email protected]>
>
> The IMA hook to measure kernel critical data, namely
> ima_measure_critical_data(), could be called before a custom IMA policy
> is loaded.
> Define a new critical data builtin policy to allow measuring
> early kernel integrity critical data before a custom IMA policy is
> loaded.
Everything needing to be said seems to be included in the second
sentence. Does the first sentence add anything? "Define a new
critical data builtin policy" makes for a good Subject line.
>
> Add critical data to built-in IMA rules if the kernel command line
> contains "ima_policy=critical_data".
The boot command line parameters are defined in Documentation/admin-
guide/kernel-parameters.txt. Please update "ima_policy".
>
> Signed-off-by: Lakshmi Ramasubramanian <[email protected]>
> ---
> security/integrity/ima/ima_policy.c | 12 ++++++++++++
> 1 file changed, 12 insertions(+)
>
> diff --git a/security/integrity/ima/ima_policy.c b/security/integrity/ima/ima_policy.c
> index c9e52dab0638..119604a3efa0 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 __ro_after_init;
Unlike ima_fail_unverifiable_sigs, ima_use_critical_data is only used
during __init. Please change "__ro_after_init" to "__initdata". (The
critical data policy itself is defined properly as __ro_after_init.)
> 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
> @@ -875,6 +882,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();
> }
>
Hi Tushar, Lakshmi,
On Thu, 2020-11-19 at 15:26 -0800, Tushar Sugandhi wrote:
> From: Lakshmi Ramasubramanian <[email protected]>
>
> IMA measures files and buffer data such as keys, command line arguments
> passed to the kernel on kexec system call, etc. While these measurements
> enable monitoring and validating the integrity of the system, it is not
> sufficient.
The above paragraph would make a good cover letter introduction.
> In-memory data structures maintained by various kernel
> components store the current state and policies configured for
> the components.
Various data structures, policies and state stored in kernel memory
also impact the integrity of the system.
The 2nd paragraph could provide examples of such integrity critical
data.
This patch set introduces a new IMA hook named
ima_measure_critical_data() to measure kernel integrity critical data.
thanks,
Mimi
On 11/20/20 6:30 AM, Mimi Zohar wrote:
Hi Mimi,
>
> On Thu, 2020-11-19 at 15:26 -0800, Tushar Sugandhi wrote:
>> From: Lakshmi Ramasubramanian <[email protected]>
>>
>> The IMA hook to measure kernel critical data, namely
>> ima_measure_critical_data(), could be called before a custom IMA policy
>> is loaded.
>> Define a new critical data builtin policy to allow measuring
>> early kernel integrity critical data before a custom IMA policy is
>> loaded.
>
> Everything needing to be said seems to be included in the second
> sentence. Does the first sentence add anything? "Define a new
> critical data builtin policy" makes for a good Subject line.
Agreed - will update.
>
>>
>> Add critical data to built-in IMA rules if the kernel command line
>> contains "ima_policy=critical_data".
>
> The boot command line parameters are defined in Documentation/admin-
> guide/kernel-parameters.txt. Please update "ima_policy".
Will do.
>
>>
>> Signed-off-by: Lakshmi Ramasubramanian <[email protected]>
>> ---
>> security/integrity/ima/ima_policy.c | 12 ++++++++++++
>> 1 file changed, 12 insertions(+)
>>
>> diff --git a/security/integrity/ima/ima_policy.c b/security/integrity/ima/ima_policy.c
>> index c9e52dab0638..119604a3efa0 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 __ro_after_init;
>
> Unlike ima_fail_unverifiable_sigs, ima_use_critical_data is only used
> during __init. Please change "__ro_after_init" to "__initdata". (The
> critical data policy itself is defined properly as __ro_after_init.)
Will do.
>
>> 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
>> @@ -875,6 +882,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();
>> }
>>
>
thanks,
-lakshmi
On 11/20/20 7:49 AM, Mimi Zohar wrote:
Hi Mimi,
>
> On Thu, 2020-11-19 at 15:26 -0800, Tushar Sugandhi wrote:
>> From: Lakshmi Ramasubramanian <[email protected]>
>>
>> IMA measures files and buffer data such as keys, command line arguments
>> passed to the kernel on kexec system call, etc. While these measurements
>> enable monitoring and validating the integrity of the system, it is not
>> sufficient.
>
> The above paragraph would make a good cover letter introduction.
Agreed - will add this paragraph to the cover letter as well.
>
>> In-memory data structures maintained by various kernel
>> components store the current state and policies configured for
>> the components.
>
> Various data structures, policies and state stored in kernel memory
> also impact the integrity of the system.
Will update.
>
> The 2nd paragraph could provide examples of such integrity critical
> data.
Will do.
>
> This patch set introduces a new IMA hook named
> ima_measure_critical_data() to measure kernel integrity critical data.
>
*Question*
I am not clear about this one - do you mean add the following line in
the patch description for the selinux patch?
"This patch introduces the first use of the new IMA hook namely
ima_measures_critical_data() to measure the integrity critical data for
SELinux"
thanks,
-lakshmi
On Thu, 19 Nov 2020, Tushar Sugandhi wrote:
> an impact on the security guarantees provided by SELinux. Measuring
> such in-memory data structures through IMA subsystem provides a secure
> way for a remote attestation service to know the state of the system
> and also the runtime changes in the state of the system.
I think we need better clarity on the security model here than just "a
secure way...". Secure how and against what threats?
This looks to me like configuration assurance, i.e. you just want to know
that systems have been configured correctly, not to detect a competent
attack. Is that correct?
--
James Morris
<[email protected]>
Hi!
> >How is it supposed to be useful?
> >
> >I'm pretty sure there are critical data that are not measured by
> >proposed module... and that are written under normal circumstances.
> >
> The goal of this series is to introduce the IMA hook
> measure_critical_data() and the necessary policies to use it; and
> illustrate that use with one example (SELinux). It is not scalable to
> identify and update all the critical data sources to use the proposed
> module at once.
>
> A piecemeal approach to add more critical data measurement in subsequent
> patches would be easy to implement and review.
Basically every other data structure in kernel is "critical" by your
definition, and you can't really measure them all; some of them change
rather often. Going piecemeal does not really help here.
Example of critical data structure: page table entries for process I
own.
Best regards,
Pavel
--
http://www.livejournal.com/~pavelmachek
Thanks Pavel for looking at this series.
On 2020-11-20 4:46 a.m., Pavel Machek wrote:
> On Thu 2020-11-19 15:26:03, Tushar Sugandhi wrote:
>> Kernel integrity critical data can be defined as the in-memory kernel
>> data which if accidentally or maliciously altered, can compromise the
>> integrity of the system.
>
> Is that an useful definition?
I will rework on the definition in the next iteration.
Meanwhile, if you have any feedback on what can we add to the
definition, that would help is.
>
>> There are several kernel subsystems that contain integrity critical
>> data - e.g. LSMs like SELinux, or AppArmor; or device-mapper targets
>> like dm-crypt, dm-verity etc. Examples of critical data could be kernel
>> in-memory r/o structures, hash of the memory structures, or data that
>> represents a linux kernel subsystem state.
>>
>> This patch set defines a new IMA hook namely ima_measure_critical_data()
>> to measure the critical data. Kernel subsystems can use this
>> functionality, to take advantage of IMA's measuring and quoting
>> abilities - thus ultimately enabling remote attestation for the
>> subsystem specific information stored in the kernel memory.
>
> How is it supposed to be useful?
>
> I'm pretty sure there are critical data that are not measured by
> proposed module... and that are written under normal circumstances.
>
The goal of this series is to introduce the IMA hook
measure_critical_data() and the necessary policies to use it; and
illustrate that use with one example (SELinux). It is not scalable to
identify and update all the critical data sources to use the proposed
module at once.
A piecemeal approach to add more critical data measurement in subsequent
patches would be easy to implement and review.
Please let me know if you have more thoughts on this. (what critical
data you think would be useful to measure etc.)
~Tushar
> Best regards,
>
> Pavel
>
Hi Pavel,
On Sun, 2020-11-22 at 22:00 +0100, Pavel Machek wrote:
> Hi!
>
> > >How is it supposed to be useful?
> > >
> > >I'm pretty sure there are critical data that are not measured by
> > >proposed module... and that are written under normal circumstances.
> > >
> > The goal of this series is to introduce the IMA hook
> > measure_critical_data() and the necessary policies to use it; and
> > illustrate that use with one example (SELinux). It is not scalable to
> > identify and update all the critical data sources to use the proposed
> > module at once.
> >
> > A piecemeal approach to add more critical data measurement in subsequent
> > patches would be easy to implement and review.
>
> Basically every other data structure in kernel is "critical" by your
> definition, and you can't really measure them all; some of them change
> rather often. Going piecemeal does not really help here.
Agreed, measuring data structures that change is not really applicable.
However, measuring data structures that once initialized don't change,
does make sense (similar concept to __ro_after_init). The attestation
server doesn't need to know anything about the measurement, other than
more than a single measurement is indicative of a problem.
Mimi
> Example of critical data structure: page table entries for process I
> own.
Hi!
> > > >How is it supposed to be useful?
> > > >
> > > >I'm pretty sure there are critical data that are not measured by
> > > >proposed module... and that are written under normal circumstances.
> > > >
> > > The goal of this series is to introduce the IMA hook
> > > measure_critical_data() and the necessary policies to use it; and
> > > illustrate that use with one example (SELinux). It is not scalable to
> > > identify and update all the critical data sources to use the proposed
> > > module at once.
> > >
> > > A piecemeal approach to add more critical data measurement in subsequent
> > > patches would be easy to implement and review.
> >
> > Basically every other data structure in kernel is "critical" by your
> > definition, and you can't really measure them all; some of them change
> > rather often. Going piecemeal does not really help here.
>
> Agreed, measuring data structures that change is not really applicable.
> However, measuring data structures that once initialized don't change,
> does make sense (similar concept to __ro_after_init). The attestation
> server doesn't need to know anything about the measurement, other than
> more than a single measurement is indicative of a problem.
So, why not simply measure everything that is ro_after_init?
But... I really fail to see how this is useful. It is trivial to
"backdoor" kernel w/o modifying anything that is
ro_after_init. (Example: page tables).
Pavel
--
http://www.livejournal.com/~pavelmachek
Hi James,
On 2020-11-20 6:05 p.m., James Morris wrote:
> On Thu, 19 Nov 2020, Tushar Sugandhi wrote:
>
>> an impact on the security guarantees provided by SELinux. Measuring
>> such in-memory data structures through IMA subsystem provides a secure
>> way for a remote attestation service to know the state of the system
>> and also the runtime changes in the state of the system.
>
> I think we need better clarity on the security model here than just "a
> secure way...". Secure how and against what threats?
>
Thanks for taking a look at this patch series.
Here is the overall threat model:
For a given device inside an organization, various services/
infrastructure tools owned by the org interact with the device. These
services/tools can be external to the device. They can interact with the
device both during setup and rest of the device lifetime. These
interactions may involve sharing the org sensitive data and/or running
business critical workload on that device. Before sharing data/running
workload on that device - the org would want to know the security
profile of the device. E.g. SELinux is enforced (with the policy that is
expected by the org), disks are encrypted with a certain configuration,
secure boot is enabled etc. If the org requirements are satisfied, then
only the external services will start interacting with the device.
For the org, extracting that information from the device is tricky.
The services could look for some markers on the device necessary to
satisfy the org requirements. But the device could already be
compromised with some malware, and could simply lie to the external
services by putting false markers on the device. For instance, the
malware can put a random SELinux policy file at the expected location
even when SELinux is not even enabled on the device.
If the org trusts these false markers, the compromised device could go
undetected - and can do further damage once it has access to the org
sensitive data / business critical processes.
This is the threat we are trying to address.
For the org, to address this threat - at least three things are needed:
(1) Producers of the markers are as close to the source as possible:
The source that does the work of actually protecting the device.
E.g. SELinux state reported from the SELinux kernel LVM itself, rather
than some user mode process extracting that information).
This will make it harder for the bad actors to mimic the information -
thus reducing the ROI for them.
(2) Extracting the information from the device in a tamper resistant
way:
Even if the information is produced by the expected source, it can still
get altered by attackers. This can happen before the info reaches the
external services - the services that make the decision whether to trust
the device with org sensitive info or not.
The IMA measurement infrastructure, with TPM extend and quoting,
provides the necessary assurance to those services - that the
information coming from the device is not tampered with.
(3) Tracking the state change during the lifetime of the device:
The device may start in a good configuration. But over the lifetime,
that configuration may deteriorate. E.g. SELinux stores the
current operating mode, in memory, which could be "enforce" or "audit".
Changes to this data at runtime impacts the security guarantees provided
by SELinux. Such changes could be made inadvertently or by malware
running on the device.
The IMA hook plus policies in the first 7/8 patches provide the
necessary functionality to achieve (2).
The last SELinux 8/8 patch helps achieve (1).
And the patches in the series overall work together to achieve (3).
> This looks to me like configuration assurance, i.e. you just want to know
> that systems have been configured correctly, not to detect a competent
> attack. Is that correct?
The attestation service would look at various measurements coming from
the device. And there could be a discrepancy between the measurements,
or the measurements won't match the expected predetermined values. In
that case, the attestation service may conclude that not only the device
is misconfigured, but also that misconfiguration is a result of
potentially compromised device. Then the necessary action can be taken
for the device (removing it from the network, not sharing data/workload
with it etc.)
~Tushar
On Mon, 2020-11-23 at 18:18 +0100, Pavel Machek wrote:
> > > Basically every other data structure in kernel is "critical" by your
> > > definition, and you can't really measure them all; some of them change
> > > rather often. Going piecemeal does not really help here.
> >
> > Agreed, measuring data structures that change is not really applicable.
> > However, measuring data structures that once initialized don't change,
> > does make sense (similar concept to __ro_after_init). The attestation
> > server doesn't need to know anything about the measurement, other than
> > more than a single measurement is indicative of a problem.
>
> So, why not simply measure everything that is ro_after_init?
I guess we could, but the original discussion, a long time ago prior to
LSM stacking, was limited to measuring the LSM hooks.
Mimi