[PATCH v2] IMA: support for duplicate data measurement
IMA does not measure duplicate data since TPM extend is a very expensive
operation. However, in some cases, the measurement of duplicate data
is necessary to accurately determine the current state of the system.
Eg, SELinux state changing from 'audit', to 'enforcing', and back to
'audit' again. In this example, currently, IMA will not measure the
last state change to 'audit'. This limits the ability of attestation
services to accurately determine the current state of the measurements
on the system.
Update ima_add_template_entry() to support measurement of duplicate
data, driven by a Kconfig option - IMA_DISABLE_HTABLE.
Signed-off-by: Tushar Sugandhi
---
Change Log v2:
- Incorporated feedback from Mimi on v1.
- The fix is not just applicable to measurement of critical data,
it now applies to other buffers and file data as well.
- the fix is driven by a Kconfig option IMA_DISABLE_HTABLE, rather
than a IMA policy condition - allow_dup.
security/integrity/ima/Kconfig | 7 +++
security/integrity/ima/ima_queue.c | 5 +++--
2 files changed, 10 insertions(+), 2 deletions(-)
diff --git a/security/integrity/ima/Kconfig b/security/integrity/ima/Kconfig
index 12e9250c1bec..057c20b46587 100644
--- a/security/integrity/ima/Kconfig
+++ b/security/integrity/ima/Kconfig
@@ -334,3 +334,10 @@ config IMA_SECURE_AND_OR_TRUSTED_BOOT
help
This option is selected by architectures to enable secure and/or
trusted boot based on IMA runtime policies.
+
+config IMA_DISABLE_HTABLE
+ bool "disable htable to allow measurement of duplicate data"
+ depends on IMA
+ default n
+ help
+ This option disables htable to allow measurement of duplicate data.
diff --git a/security/integrity/ima/ima_queue.c
b/security/integrity/ima/ima_queue.c
index c096ef8945c7..532da87ce519 100644
--- a/security/integrity/ima/ima_queue.c
+++ b/security/integrity/ima/ima_queue.c
@@ -168,7 +168,7 @@ int ima_add_template_entry(struct ima_template_entry
*entry, int violation,
int result = 0, tpmresult = 0;
mutex_lock(&ima_extend_list_mutex);
- if (!violation) {
+ if (!violation && !IS_ENABLED(CONFIG_IMA_DISABLE_HTABLE)) {
if (ima_lookup_digest_entry(digest, entry->pcr)) {
audit_cause = "hash_exists";
result = -EEXIST;
@@ -176,7 +176,8 @@ int ima_add_template_entry(struct ima_template_entry
*entry, int violation,
}
}
- result = ima_add_digest_entry(entry, 1);
+ result = ima_add_digest_entry(entry,
+ !IS_ENABLED(CONFIG_IMA_DISABLE_HTABLE));
if (result < 0) {
audit_cause = "ENOMEM";
audit_info = 0;
--
2.17.1
Re: [PATCH v3] IMA: support for duplicate measurement records
Hello Petr, On 2021-02-23 4:18 p.m., Petr Vorel wrote: Hi Tushar, Change Log v3: - Incorporated feedback from Mimi on v2. - Updated patch title and description to make it generic. - Changed config description word 'data' to 'records'. - Tested use cases for boot param "ima_policy=tcb". LGTM. Reviewed-by: Petr Vorel Thank you taking a look at the patch, and the 'Reviewed-by' tag. ~Tushar Kind regards, Petr
Re: [PATCH v2] IMA: support for duplicate data measurement
Thanks for the feedback Mimi. Appreciate it. On 2021-02-17 7:03 a.m., Mimi Zohar wrote: Hi Tushar, The Subject line could be improved. Perhaps something like - "IMA: support for duplicate measurement records" Will do. On Tue, 2021-02-16 at 18:46 -0800, Tushar Sugandhi wrote: IMA does not measure duplicate data since TPM extend is a very expensive operation. However, in some cases, the measurement of duplicate data is necessary to accurately determine the current state of the system. Eg, SELinux state changing from 'audit', to 'enforcing', and back to 'audit' again. In this example, currently, IMA will not measure the last state change to 'audit'. This limits the ability of attestation services to accurately determine the current state of the measurements on the system. This patch description is written from your specific usecase perspective, but it impacts file and buffer data measurements as well, not only critical data measurements. In all of these situations, with this patch a new measurement record is added/appended to the measurement list. Please re-write the patch description making it more generic. For example, I would start with something like, "IMA does not include duplicate file, buffer or critical data measurement records ..." Agreed. I will generalize the description further and send the v3 for review. Thanks, Tushar thanks, Mimi Update ima_add_template_entry() to support measurement of duplicate data, driven by a Kconfig option - IMA_DISABLE_HTABLE. Signed-off-by: Tushar Sugandhi
Re: [PATCH v2] IMA: support for duplicate data measurement
On 2021-02-17 12:39 p.m., Mimi Zohar wrote: On Wed, 2021-02-17 at 10:53 -0800, Tushar Sugandhi wrote: Thanks for the feedback Mimi. Appreciate it. On 2021-02-17 7:03 a.m., Mimi Zohar wrote: Hi Tushar, The Subject line could be improved. Perhaps something like - "IMA: support for duplicate measurement records" Will do. On Tue, 2021-02-16 at 18:46 -0800, Tushar Sugandhi wrote: IMA does not measure duplicate data since TPM extend is a very expensive operation. However, in some cases, the measurement of duplicate data is necessary to accurately determine the current state of the system. Eg, SELinux state changing from 'audit', to 'enforcing', and back to 'audit' again. In this example, currently, IMA will not measure the last state change to 'audit'. This limits the ability of attestation services to accurately determine the current state of the measurements on the system. This patch description is written from your specific usecase perspective, but it impacts file and buffer data measurements as well, not only critical data measurements. In all of these situations, with this patch a new measurement record is added/appended to the measurement list. Please re-write the patch description making it more generic. For example, I would start with something like, "IMA does not include duplicate file, buffer or critical data measurement records ..." Agreed. I will generalize the description further and send the v3 for review. It would be good to boot with the ima_policy=tcb policy with/without your patch and account for the different number of measurements. Are all the differences related to duplicate measurements - original file hash -> new file hash -> original file hash - similar to what you described. Thanks for the ima_policy=tcb pointer. I tested my patch with: - duplicate buffer content for "measure func=CRITICAL_DATA" - and reading the same file twice with "measure func=FILE_CHECK mask=MAY_READ" In both the above use cases, IMA is measuring the duplicate entries with the patch, and not measuring the duplicate entries w/o the patch. I will test the "ima_policy=tcb" boot-scenario as you suggested, before posting the next version. Thanks, Tushar thanks, Mimi
Re: [PATCH v2] IMA: support for duplicate data measurement
Hi Mimi, On 2021-02-17 12:49 p.m., Tushar Sugandhi wrote: On 2021-02-17 12:39 p.m., Mimi Zohar wrote: On Wed, 2021-02-17 at 10:53 -0800, Tushar Sugandhi wrote: Thanks for the feedback Mimi. Appreciate it. On 2021-02-17 7:03 a.m., Mimi Zohar wrote: Hi Tushar, The Subject line could be improved. Perhaps something like - "IMA: support for duplicate measurement records" Will do. On Tue, 2021-02-16 at 18:46 -0800, Tushar Sugandhi wrote: IMA does not measure duplicate data since TPM extend is a very expensive operation. However, in some cases, the measurement of duplicate data is necessary to accurately determine the current state of the system. Eg, SELinux state changing from 'audit', to 'enforcing', and back to 'audit' again. In this example, currently, IMA will not measure the last state change to 'audit'. This limits the ability of attestation services to accurately determine the current state of the measurements on the system. This patch description is written from your specific usecase perspective, but it impacts file and buffer data measurements as well, not only critical data measurements. In all of these situations, with this patch a new measurement record is added/appended to the measurement list. Please re-write the patch description making it more generic. For example, I would start with something like, "IMA does not include duplicate file, buffer or critical data measurement records ..." Agreed. I will generalize the description further and send the v3 for review. It would be good to boot with the ima_policy=tcb policy with/without your patch and account for the different number of measurements. Are all the differences related to duplicate measurements - original file hash -> new file hash -> original file hash - similar to what you described. Thanks for the ima_policy=tcb pointer. I tested my patch with: - duplicate buffer content for "measure func=CRITICAL_DATA" - and reading the same file twice with "measure func=FILE_CHECK mask=MAY_READ" In both the above use cases, IMA is measuring the duplicate entries with the patch, and not measuring the duplicate entries w/o the patch. I will test the "ima_policy=tcb" boot-scenario as you suggested, before posting the next version. I booted the system with "ima_policy=tcb" policy with/without my patch. I also removed /etc/ima/ima-policy for testing these use-cases. (so that it wouldn't override the policy generated by boot param "ima_policy=tcb"). I double checked the contents of the kernel policy: #cat /sys/kernel/security/integrity/ima/policy dont_measure fsmagic=0x9fa0 dont_measure fsmagic=0x62656572 dont_measure fsmagic=0x64626720 dont_measure fsmagic=0x1021994 dont_measure fsmagic=0x1cd1 dont_measure fsmagic=0x42494e4d dont_measure fsmagic=0x73636673 dont_measure fsmagic=0xf97cff8c dont_measure fsmagic=0x43415d53 dont_measure fsmagic=0x27e0eb dont_measure fsmagic=0x63677270 dont_measure fsmagic=0x6e736673 dont_measure fsmagic=0xde5e81e4 measure func=MMAP_CHECK mask=MAY_EXEC measure func=BPRM_CHECK mask=MAY_EXEC measure func=FILE_CHECK mask=^MAY_READ euid=0 measure func=FILE_CHECK mask=^MAY_READ uid=0 measure func=MODULE_CHECK measure func=FIRMWARE_CHECK measure func=POLICY_CHECK And then I compared the contents of the ascii_runtime_measurements with and without my patch. And here are my findings: (1) Files like systemd-udevd, x2go_sessions etc. get measured multiple times with the CONFIG_IMA_DISABLE_HTABLE=y. They only get measured once with the config "=n". 10 668df8723f5a1f57a0afe3b50d44054d66363f3e ima-ng sha1:51f66e82421b93b21ad1e0a25e5efa4155c6a8e0 /lib/systemd/systemd-udevd 10 668df8723f5a1f57a0afe3b50d44054d66363f3e ima-ng sha1:51f66e82421b93b21ad1e0a25e5efa4155c6a8e0 /lib/systemd/systemd-udevd (2) There are lot more instances of /tmp/ measurement records with the CONFIG_IMA_DISABLE_HTABLE=y. Eg, 10 33515851cfee4acbf24de9482ff018d33def1083 ima-ng sha1:da39a3ee5e6b4b0d3255bfef95601890afd80709 /tmp/oUWCVeypLR 10 9d1dc0e1e54ee2e16308a824fc5780bd21b38208 ima-ng sha1:da39a3ee5e6b4b0d3255bfef95601890afd80709 /tmp/etX8dy7qqy 10 8643a5543179b86c02d7e3e01e16b3bd2f8dbb9f ima-ng sha1:da39a3ee5e6b4b0d3255bfef95601890afd80709 /tmp/I4zTWEuyMf 10 56e9547a4ed39036d2e790cfad78b467aa979e32 ima-ng sha1:da39a3ee5e6b4b0d3255bfef95601890afd80709 /tmp/Lh5wDm6_Ep I believe both the observations are consistent with the expected outcome of the patch. Please let me know if I should test any other scenario. I will shortly post the v3 patch with updates to description and title as you suggested. Thanks, Tushar Thanks, Tushar thanks, Mimi
[PATCH v3] IMA: support for duplicate measurement records
IMA does not include duplicate file, buffer, or critical data
measurement records since TPM extend is a very expensive
operation. However, in some cases, the measurement of duplicate
records is necessary to accurately determine the current state of the
system. For instance - the file, buffer, or critical data measurement
record may change from some value 'val#1', to 'val#2', and then back
to 'val#1'. Currently, IMA will not measure the last change to 'val#1',
since the hash of 'val#1' for the given record is already present in the
measurement log. This limits the ability of the attestation service to
accurately determine the current state of the system, because it would
be interpreted as the system having 'val#2' for the given record.
Update ima_add_template_entry() to support measurement of duplicate
records, driven by a Kconfig option - IMA_DISABLE_HTABLE.
Signed-off-by: Tushar Sugandhi
---
Change Log v3:
- Incorporated feedback from Mimi on v2.
- Updated patch title and description to make it generic.
- Changed config description word 'data' to 'records'.
- Tested use cases for boot param "ima_policy=tcb".
Change Log v2:
- Incorporated feedback from Mimi on v1.
- The fix is not just applicable to measurement of critical data,
it now applies to other buffers and file data as well.
- the fix is driven by a Kconfig option IMA_DISABLE_HTABLE, rather
than a IMA policy condition - allow_dup.
security/integrity/ima/Kconfig | 7 +++
security/integrity/ima/ima_queue.c | 5 +++--
2 files changed, 10 insertions(+), 2 deletions(-)
diff --git a/security/integrity/ima/Kconfig b/security/integrity/ima/Kconfig
index 12e9250c1bec..d0ceada99243 100644
--- a/security/integrity/ima/Kconfig
+++ b/security/integrity/ima/Kconfig
@@ -334,3 +334,10 @@ config IMA_SECURE_AND_OR_TRUSTED_BOOT
help
This option is selected by architectures to enable secure and/or
trusted boot based on IMA runtime policies.
+
+config IMA_DISABLE_HTABLE
+ bool "Disable htable to allow measurement of duplicate records"
+ depends on IMA
+ default n
+ help
+ This option disables htable to allow measurement of duplicate
records.
diff --git a/security/integrity/ima/ima_queue.c
b/security/integrity/ima/ima_queue.c
index c096ef8945c7..532da87ce519 100644
--- a/security/integrity/ima/ima_queue.c
+++ b/security/integrity/ima/ima_queue.c
@@ -168,7 +168,7 @@ int ima_add_template_entry(struct ima_template_entry
*entry, int violation,
int result = 0, tpmresult = 0;
mutex_lock(&ima_extend_list_mutex);
- if (!violation) {
+ if (!violation && !IS_ENABLED(CONFIG_IMA_DISABLE_HTABLE)) {
if (ima_lookup_digest_entry(digest, entry->pcr)) {
audit_cause = "hash_exists";
result = -EEXIST;
@@ -176,7 +176,8 @@ int ima_add_template_entry(struct ima_template_entry
*entry, int violation,
}
}
- result = ima_add_digest_entry(entry, 1);
+ result = ima_add_digest_entry(entry,
+ !IS_ENABLED(CONFIG_IMA_DISABLE_HTABLE));
if (result < 0) {
audit_cause = "ENOMEM";
audit_info = 0;
--
2.17.1
[PATCH 2/3] IMA: update functions to read allow_dup policy condition
IMA functions ima_get_action() and ima_match_policy() do not consume the
policy condition to allow measuring duplicate entries for integrity
critical data.
Update ima_get_action() and ima_match_policy() to consume the IMA policy
condition to measure duplicate buffer entries for integrity critical
data.
Signed-off-by: Tushar Sugandhi
---
security/integrity/ima/ima.h | 4 ++--
security/integrity/ima/ima_api.c | 6 --
security/integrity/ima/ima_appraise.c | 2 +-
security/integrity/ima/ima_main.c | 6 +++---
security/integrity/ima/ima_policy.c | 7 ++-
5 files changed, 16 insertions(+), 9 deletions(-)
diff --git a/security/integrity/ima/ima.h b/security/integrity/ima/ima.h
index aa312472c7c5..59324173497f 100644
--- a/security/integrity/ima/ima.h
+++ b/security/integrity/ima/ima.h
@@ -257,7 +257,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 *func_data);
+ const char *func_data, bool *allow_dup);
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,
@@ -286,7 +286,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 *func_data);
+const char *func_data, bool *allow_dup);
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 1dd70dc68ffd..d273373e6be9 100644
--- a/security/integrity/ima/ima_api.c
+++ b/security/integrity/ima/ima_api.c
@@ -171,6 +171,8 @@ void ima_add_violation(struct file *file, const unsigned
char *filename,
* @pcr: pointer filled in if matched measure policy sets pcr=
* @template_desc: pointer filled in if matched measure policy sets template=
* @func_data: func specific data, may be NULL
+ * @allow_dup: pointer filled in to decide if a duplicate buffer entry
+ * should be measured
*
* The policy is defined in terms of keypairs:
* subj=, obj=, type=, func=, mask=, fsmagic=
@@ -186,14 +188,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 *func_data)
+ const char *func_data, bool *allow_dup)
{
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, func_data);
+ template_desc, func_data, allow_dup);
}
/*
diff --git a/security/integrity/ima/ima_appraise.c
b/security/integrity/ima/ima_appraise.c
index 46ffa38bab12..e317a7698a47 100644
--- a/security/integrity/ima/ima_appraise.c
+++ b/security/integrity/ima/ima_appraise.c
@@ -77,7 +77,7 @@ int ima_must_appraise(struct inode *inode, int mask, enum
ima_hooks func)
security_task_getsecid(current, &secid);
return ima_match_policy(inode, current_cred(), secid, func, mask,
- IMA_APPRAISE | IMA_HASH, NULL, NULL, NULL);
+ IMA_APPRAISE | IMA_HASH, NULL, NULL, NULL,
NULL);
}
static int ima_fix_xattr(struct dentry *dentry,
diff --git a/security/integrity/ima/ima_main.c
b/security/integrity/ima/ima_main.c
index 6a429846f90a..2774139845b6 100644
--- a/security/integrity/ima/ima_main.c
+++ b/security/integrity/ima/ima_main.c
@@ -219,7 +219,7 @@ static int process_measurement(struct file *file, const
struct cred *cred,
* Included is the appraise submask.
*/
action = ima_get_action(inode, cred, secid, mask, func, &pcr,
- &template_desc, NULL);
+ &template_desc, NULL, NULL);
violation_check = ((func == FILE_CHECK || func == MMAP_CHECK) &&
(ima_policy_flag & IMA_MEASURE));
if (!action && !violation_check)
@@ -432,7 +432,7 @@ int ima_file_mprotect(struct vm_area_struct *vma, unsigned
long prot)
security_task_getsecid(current, &secid);
inode = file_inode(vma->vm_file);
action = ima_ge
[PATCH 3/3] IMA: add support to measure duplicate buffer for critical data hook
process_buffer_measurement() and the underlying functions do not use the
policy condition to measure duplicate buffer entries for integrity
critical data.
Update process_buffer_measurement(), ima_add_template_entry(), and
ima_store_template() to use the policy condition to decide if a
duplicate buffer entry for integrity critical data should be measured.
Signed-off-by: Tushar Sugandhi
---
security/integrity/ima/ima.h | 4 ++--
security/integrity/ima/ima_api.c | 9 +
security/integrity/ima/ima_init.c | 2 +-
security/integrity/ima/ima_main.c | 5 +++--
security/integrity/ima/ima_queue.c | 5 +++--
5 files changed, 14 insertions(+), 11 deletions(-)
diff --git a/security/integrity/ima/ima.h b/security/integrity/ima/ima.h
index 59324173497f..b06732560949 100644
--- a/security/integrity/ima/ima.h
+++ b/security/integrity/ima/ima.h
@@ -139,7 +139,7 @@ int ima_init(void);
int ima_fs_init(void);
int ima_add_template_entry(struct ima_template_entry *entry, int violation,
const char *op, struct inode *inode,
- const unsigned char *filename);
+ const unsigned char *filename, bool allow_dup);
int ima_calc_file_hash(struct file *file, struct ima_digest_data *hash);
int ima_calc_buffer_hash(const void *buf, loff_t len,
struct ima_digest_data *hash);
@@ -278,7 +278,7 @@ int ima_alloc_init_template(struct ima_event_data
*event_data,
struct ima_template_desc *template_desc);
int ima_store_template(struct ima_template_entry *entry, int violation,
struct inode *inode,
- const unsigned char *filename, int pcr);
+ const unsigned char *filename, int pcr, bool allow_dup);
void ima_free_template_entry(struct ima_template_entry *entry);
const char *ima_d_path(const struct path *path, char **pathbuf, char
*filename);
diff --git a/security/integrity/ima/ima_api.c b/security/integrity/ima/ima_api.c
index d273373e6be9..f84369f9905e 100644
--- a/security/integrity/ima/ima_api.c
+++ b/security/integrity/ima/ima_api.c
@@ -101,7 +101,7 @@ int ima_alloc_init_template(struct ima_event_data
*event_data,
*/
int ima_store_template(struct ima_template_entry *entry,
int violation, struct inode *inode,
- const unsigned char *filename, int pcr)
+ const unsigned char *filename, int pcr, bool allow_dup)
{
static const char op[] = "add_template_measure";
static const char audit_cause[] = "hashing_error";
@@ -119,7 +119,8 @@ int ima_store_template(struct ima_template_entry *entry,
}
}
entry->pcr = pcr;
- result = ima_add_template_entry(entry, violation, op, inode, filename);
+ result = ima_add_template_entry(entry, violation, op, inode, filename,
+ allow_dup);
return result;
}
@@ -152,7 +153,7 @@ void ima_add_violation(struct file *file, const unsigned
char *filename,
goto err_out;
}
result = ima_store_template(entry, violation, inode,
- filename, CONFIG_IMA_MEASURE_PCR_IDX);
+ filename, CONFIG_IMA_MEASURE_PCR_IDX,
false);
if (result < 0)
ima_free_template_entry(entry);
err_out:
@@ -330,7 +331,7 @@ void ima_store_measurement(struct integrity_iint_cache
*iint,
return;
}
- result = ima_store_template(entry, violation, inode, filename, pcr);
+ result = ima_store_template(entry, violation, inode, filename, pcr,
false);
if ((!result || result == -EEXIST) && !(file->f_flags & O_DIRECT)) {
iint->flags |= IMA_MEASURED;
iint->measured_pcrs |= (0x1 << pcr);
diff --git a/security/integrity/ima/ima_init.c
b/security/integrity/ima/ima_init.c
index 6e8742916d1d..d0a79d7b8d89 100644
--- a/security/integrity/ima/ima_init.c
+++ b/security/integrity/ima/ima_init.c
@@ -88,7 +88,7 @@ static int __init ima_add_boot_aggregate(void)
result = ima_store_template(entry, violation, NULL,
boot_aggregate_name,
- CONFIG_IMA_MEASURE_PCR_IDX);
+ CONFIG_IMA_MEASURE_PCR_IDX, false);
if (result < 0) {
ima_free_template_entry(entry);
audit_cause = "store_entry";
diff --git a/security/integrity/ima/ima_main.c
b/security/integrity/ima/ima_main.c
index 2774139845b6..ff6d15d7594c 100644
--- a/security/integrity/ima/ima_main.c
+++ b/security/integrity/ima/ima_main.c
@@ -843,6 +843,7 @@ void process_buffer_measurement(struct inode *inode, const
void *buf, int size,
int digest_hash_len = hash_digest_size[ima_hash_algo];
int violation = 0;
[PATCH 1/3] IMA: add policy condition to measure duplicate critical data
IMA needs to support duplicate measurements of integrity
critical data to accurately determine the current state of that data
on the system. Further, since measurement of duplicate data is not
required for all the use cases, it needs to be policy driven.
Define "allow_dup", a new IMA policy condition, for the IMA func
CRITICAL_DATA to allow duplicate buffer measurement of integrity
critical data.
Limit the ability to measure duplicate buffer data when action is
"measure" and func is CRITICAL_DATA.
Signed-off-by: Tushar Sugandhi
---
Documentation/ABI/testing/ima_policy | 4 +++-
security/integrity/ima/ima_policy.c | 24 ++--
2 files changed, 25 insertions(+), 3 deletions(-)
diff --git a/Documentation/ABI/testing/ima_policy
b/Documentation/ABI/testing/ima_policy
index bc8e1cbe5e61..9598287e3bbf 100644
--- a/Documentation/ABI/testing/ima_policy
+++ b/Documentation/ABI/testing/ima_policy
@@ -27,7 +27,7 @@ Description:
lsm:[[subj_user=] [subj_role=] [subj_type=]
[obj_user=] [obj_role=] [obj_type=]]
option: [[appraise_type=]] [template=] [permit_directio]
- [appraise_flag=] [keyrings=]
+ [appraise_flag=] [keyrings=] [allow_dup]
base:
func:=
[BPRM_CHECK][MMAP_CHECK][CREDS_CHECK][FILE_CHECK]MODULE_CHECK]
[FIRMWARE_CHECK]
@@ -55,6 +55,8 @@ Description:
label:= [selinux]|[kernel_info]|[data_label]
data_label:= a unique string used for grouping and
limiting critical data.
For example, "selinux" to measure critical data for
SELinux.
+ allow_dup allows measurement of duplicate data. 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 9b45d064a87d..b89eb768dd05 100644
--- a/security/integrity/ima/ima_policy.c
+++ b/security/integrity/ima/ima_policy.c
@@ -35,6 +35,7 @@
#define IMA_FSNAME 0x0200
#define IMA_KEYRINGS 0x0400
#define IMA_LABEL 0x0800
+#define IMA_ALLOW_DUP 0x1000
#define UNKNOWN0
#define MEASURE0x0001 /* same as IMA_MEASURE */
@@ -87,6 +88,7 @@ struct ima_rule_entry {
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 */
+ bool allow_dup; /* Allow duplicate buffer entry measurement */
struct ima_template_desc *template;
};
@@ -942,7 +944,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_label, Opt_err
+ Opt_label, Opt_allow_dup, Opt_err
};
static const match_table_t policy_tokens = {
@@ -980,6 +982,7 @@ static const match_table_t policy_tokens = {
{Opt_template, "template=%s"},
{Opt_keyrings, "keyrings=%s"},
{Opt_label, "label=%s"},
+ {Opt_allow_dup, "allow_dup"},
{Opt_err, NULL}
};
@@ -1148,7 +1151,7 @@ static bool ima_validate_rule(struct ima_rule_entry
*entry)
return false;
if (entry->flags & ~(IMA_FUNC | IMA_UID | IMA_PCR |
-IMA_LABEL))
+IMA_LABEL | IMA_ALLOW_DUP))
return false;
if (ima_rule_contains_lsm_cond(entry))
@@ -1184,6 +1187,7 @@ static int ima_parse_rule(char *rule, struct
ima_rule_entry *entry)
entry->uid_op = &uid_eq;
entry->fowner_op = &uid_eq;
entry->action = UNKNOWN;
+ entry->allow_dup = false;
while ((p = strsep(&rule, " \t")) != NULL) {
substring_t args[MAX_OPT_ARGS];
int token;
@@ -1375,6 +1379,19 @@ static int ima_parse_rule(char *rule, struct
ima_rule_entry *entry)
entry->flags |= IMA_LABEL;
break;
+ case Opt_allow_dup:
+ ima_log_string(ab, "allow_dup", NULL);
+
+ if ((entry->func != CRITICAL_DATA) ||
+ (entry->action != MEASURE)) {
+ result = -EINVAL;
+ break;
+ }
+
+ entry->allow_dup = true;
+
+ entry->flags |= IMA_ALLOW_DUP;
+ break;
case Opt_fsuuid:
[PATCH 0/3] support for duplicate measurement of integrity critical data
IMA does not measure duplicate buffer data since TPM extend is a very
expensive operation. However, in some cases for integrity critical
data, the measurement of duplicate data is necessary to accurately
determine the current state of the system. Eg, SELinux state changing
from 'audit', to 'enforcing', and back to 'audit' again. In this
example, currently, IMA will not measure the last state change to
'audit'. This limits the ability of attestation services to accurately
determine the current state of the integrity critical data on the
system.
This series addresses this gap by providing the ability to measure
duplicate entries for integrity critical data, driven by policy.
This series is based on the following repo/branch/commit:
repo: https://git.kernel.org/pub/scm/linux/kernel/git/zohar/linux-integrity.git
branch: next-integrity-testing
commit b3f82afc1041 ("IMA: Measure kernel version in early boot")
Tushar Sugandhi (3):
IMA: add policy condition to measure duplicate critical data
IMA: update functions to read allow_dup policy condition
IMA: add support to measure duplicate buffer for critical data hook
Documentation/ABI/testing/ima_policy | 4 +++-
security/integrity/ima/ima.h | 8 +++
security/integrity/ima/ima_api.c | 15 +++--
security/integrity/ima/ima_appraise.c | 2 +-
security/integrity/ima/ima_init.c | 2 +-
security/integrity/ima/ima_main.c | 9
security/integrity/ima/ima_policy.c | 31 ---
security/integrity/ima/ima_queue.c| 5 +++--
8 files changed, 54 insertions(+), 22 deletions(-)
--
2.17.1
Re: [PATCH 0/3] support for duplicate measurement of integrity critical data
Thank you Mimi for reviewing this series. On 2021-02-08 1:10 p.m., Mimi Zohar wrote: Hi Tushar, On Mon, 2021-02-08 at 15:22 -0500, Mimi Zohar wrote: On Fri, 2021-01-29 at 16:45 -0800, Tushar Sugandhi wrote: IMA does not measure duplicate buffer data since TPM extend is a very expensive operation. However, in some cases for integrity critical data, the measurement of duplicate data is necessary to accurately determine the current state of the system. Eg, SELinux state changing from 'audit', to 'enforcing', and back to 'audit' again. In this example, currently, IMA will not measure the last state change to 'audit'. This limits the ability of attestation services to accurately determine the current state of the integrity critical data on the system. This series addresses this gap by providing the ability to measure duplicate entries for integrity critical data, driven by policy. The same reason for re-measuring buffer data is equally applicable to files. In both cases, the file or the buffer isn't re-measured if it already exists in the htable. Please don't limit this patch set to just buffer data. Agreed. I wasn't sure if you wanted the support for files, or other buffer measurement scenarios, except critical data. So I started the implementation with supporting just critical data. Happy to extend it to files and other buffer measurement scenarios as you suggested. Instead of making the change on a per measurement rule basis, disabling "htable" would be the simplest way of forcing re-measurements. All that would be needed is a new Kconfig (e.g. CONFIG_IMA_DISABLE_HTABLE) and the associated test in ima_add_template_entry(). Agreed. Earlier I wasn't sure if you wanted allow_dup support for all the scenarios. Now that it is clear, I will implement it as you suggested. Thank you so much for the pointers. Appreciate it. Thanks, Tushar thanks, Mimi
Re: [PATCH 1/3] IMA: add policy condition to measure duplicate critical data
On 2021-02-08 12:45 p.m., Mimi Zohar wrote:
Hi Tushar,
On Fri, 2021-01-29 at 16:45 -0800, Tushar Sugandhi wrote:
IMA needs to support duplicate measurements of integrity
critical data to accurately determine the current state of that data
on the system. Further, since measurement of duplicate data is not
required for all the use cases, it needs to be policy driven.
Define "allow_dup", a new IMA policy condition, for the IMA func
CRITICAL_DATA to allow duplicate buffer measurement of integrity
critical data.
Limit the ability to measure duplicate buffer data when action is
"measure" and func is CRITICAL_DATA.
Why?!
I wasn't sure if it would break any use-case by supporting this for all
the files / buffers. That's why I only wanted to address the scenario
that we discussed in the last series (critical data measurement).
But as you suggested in this series' cover letter response, I am happy
to extend it to other scenarios (by disabling "htable" using new Kconfig
(e.g. CONFIG_IMA_DISABLE_HTABLE)
Signed-off-by: Tushar Sugandhi
---
diff --git a/security/integrity/ima/ima_policy.c
b/security/integrity/ima/ima_policy.c
index 9b45d064a87d..b89eb768dd05 100644
--- a/security/integrity/ima/ima_policy.c
+++ b/security/integrity/ima/ima_policy.c
@@ -35,6 +35,7 @@
#define IMA_FSNAME0x0200
#define IMA_KEYRINGS 0x0400
#define IMA_LABEL 0x0800
+#define IMA_ALLOW_DUP 0x1000
#define UNKNOWN 0
#define MEASURE 0x0001 /* same as IMA_MEASURE */
@@ -87,6 +88,7 @@ struct ima_rule_entry {
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 */
Defining a new boolean entry shouldn't be necessary.The other
boolean values are just stored in "flags".
Thanks. Will do the same here.
Thanks,
Tushar
struct ima_template_desc *template;
};
thanks,
Mimi
Re: [PATCH 3/3] IMA: add support to measure duplicate buffer for critical data hook
On 2021-02-08 12:24 p.m., Mimi Zohar wrote:
Hi Tushar,
On Fri, 2021-01-29 at 16:45 -0800, Tushar Sugandhi wrote:
diff --git a/security/integrity/ima/ima_queue.c
b/security/integrity/ima/ima_queue.c
index c096ef8945c7..fbf359495fa8 100644
--- a/security/integrity/ima/ima_queue.c
+++ b/security/integrity/ima/ima_queue.c
@@ -158,7 +158,7 @@ static int ima_pcr_extend(struct tpm_digest *digests_arg,
int pcr)
*/
int ima_add_template_entry(struct ima_template_entry *entry, int violation,
const char *op, struct inode *inode,
- const unsigned char *filename)
+ const unsigned char *filename, bool allow_dup)
{
u8 *digest = entry->digests[ima_hash_algo_idx].digest;
struct tpm_digestate_entry(struct ima_template_entry *entry, int
violation,
Not sure I understand this. Maybe a typo? Could you please explain?
mutex_lock(&ima_extend_list_mutex);
if (!violation) {
- if (ima_lookup_digest_entry(digest, entry->pcr)) {
+ if (!allow_dup &&
+ ima_lookup_digest_entry(digest, entry->pcr)) {
Can't this change be simplified to "if (!violation && !allow_dup)"?
Sure. Will do.
Earlier I wasn't sure if 'violation' would touch any other use-cases
inadvertently. That's why I localized the change as above.
But now since we are supporting other scenarios as well,
I believe "if (!violation && !allow_dup)" would be cleaner.
Also perhaps instead of passing another variable "allow_dup" to each of
these functions, pass a mask containing violation and allow_dup.
There were examples of both approaches in ima_match_policy().
- int *pcr/ima_template_desc **template_desc as an out-param;
- and various actions as flags in return int.
Earlier I couldn't decide one way or the other, so I picked the
out-param approach.
But since allow_dup is just a single bit info, returning it as a bit in
the action flag is a cleaner solution.
Will implement it with flag in the next iteration.
Thanks again for reviewing the series. Really appreciate it.
Thanks,
Tushar
audit_cause = "hash_exists";
result = -EEXIST;
goto out;
thanks,
Mimi
Re: [PATCH 0/3] support for duplicate measurement of integrity critical data
On 2021-02-09 10:53 a.m., Mimi Zohar wrote: On Tue, 2021-02-09 at 10:23 -0800, Tushar Sugandhi wrote: On Mon, 2021-02-08 at 15:22 -0500, Mimi Zohar wrote: On Fri, 2021-01-29 at 16:45 -0800, Tushar Sugandhi wrote: IMA does not measure duplicate buffer data since TPM extend is a very expensive operation. However, in some cases for integrity critical data, the measurement of duplicate data is necessary to accurately determine the current state of the system. Eg, SELinux state changing from 'audit', to 'enforcing', and back to 'audit' again. In this example, currently, IMA will not measure the last state change to 'audit'. This limits the ability of attestation services to accurately determine the current state of the integrity critical data on the system. This series addresses this gap by providing the ability to measure duplicate entries for integrity critical data, driven by policy. The same reason for re-measuring buffer data is equally applicable to files. In both cases, the file or the buffer isn't re-measured if it already exists in the htable. Please don't limit this patch set to just buffer data. Agreed. I wasn't sure if you wanted the support for files, or other buffer measurement scenarios, except critical data. So I started the implementation with supporting just critical data. Happy to extend it to files and other buffer measurement scenarios as you suggested. Instead of making the change on a per measurement rule basis, disabling "htable" would be the simplest way of forcing re-measurements. All that would be needed is a new Kconfig (e.g. CONFIG_IMA_DISABLE_HTABLE) and the associated test in ima_add_template_entry(). Agreed. Earlier I wasn't sure if you wanted allow_dup support for all the scenarios. Now that it is clear, I will implement it as you suggested. Thank you so much for the pointers. Appreciate it. There are two different solutions - per measurement rule, disabling htable - being discussed. Disabling htable requires miminumal changes. Which version are you thinking of implementing? I am thinking of implementing "disabling 'htable' using a new Kconfig (e.g. CONFIG_IMA_DISABLE_HTABLE)". That is, not using the var ima_htable or ima_lookup_digest_entry() if that CONFIG is set. So the duplicate measurements are allowed when the CONFIG is set. This would cover all the measurement scenarios through a single CONFIG setting. I am not planning to implement it as a "per measurement rule". Sorry it wasn't clear in my earlier response. Thanks, Tushar thanks, Mimi
[PATCH 3/3] IMA: define IMA hook to measure critical data from kernel components
Currently, IMA does not provide a generic function to kernel components
to measure their data. A generic function provided by IMA would
enable various parts of the kernel with easier and faster on-boarding to
use IMA infrastructure, would avoid code duplication, and consistent
usage of IMA policy CRITICAL_DATA+data_sources across the kernel.
Define a generic IMA function ima_measure_critical_data() to measure
data from various kernel components. Limit the measurement to the
components that are specified in the IMA policy -
CRITICAL_DATA+data_sources.
Update process_buffer_measurement() to return the status code of the
operation.
Signed-off-by: Tushar Sugandhi
---
include/linux/ima.h | 9
security/integrity/ima/ima.h | 8 +++
security/integrity/ima/ima_main.c | 37 ---
3 files changed, 42 insertions(+), 12 deletions(-)
diff --git a/include/linux/ima.h b/include/linux/ima.h
index d15100de6cdd..865332ecedcb 100644
--- a/include/linux/ima.h
+++ b/include/linux/ima.h
@@ -26,6 +26,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 int ima_measure_critical_data(const char *event_name,
+const char *event_data_source,
+const void *buf, int buf_len);
#ifdef CONFIG_IMA_KEXEC
extern void ima_add_kexec_buffer(struct kimage *image);
@@ -104,6 +107,12 @@ 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 int ima_measure_critical_data(const char *event_name,
+ const char *event_data_source,
+ const void *buf, int buf_len)
+{
+ return -EOPNOTSUPP;
+}
#endif /* CONFIG_IMA */
#ifndef CONFIG_IMA_KEXEC
diff --git a/security/integrity/ima/ima.h b/security/integrity/ima/ima.h
index 99773dfa2541..e65ab067e700 100644
--- a/security/integrity/ima/ima.h
+++ b/security/integrity/ima/ima.h
@@ -266,10 +266,10 @@ void ima_store_measurement(struct integrity_iint_cache
*iint, struct file *file,
struct evm_ima_xattr_data *xattr_value,
int xattr_len, const struct modsig *modsig, int pcr,
struct ima_template_desc *template_desc);
-void process_buffer_measurement(struct inode *inode, const void *buf,
- int buf_len, const char *eventname,
- enum ima_hooks func, int pcr,
- const char *func_data);
+int process_buffer_measurement(struct inode *inode, const void *buf,
+ int buf_len, const char *eventname,
+ enum ima_hooks func, 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,
diff --git a/security/integrity/ima/ima_main.c
b/security/integrity/ima/ima_main.c
index a8740b7ea417..129bcaaf13e2 100644
--- a/security/integrity/ima/ima_main.c
+++ b/security/integrity/ima/ima_main.c
@@ -736,10 +736,11 @@ int ima_load_data(enum kernel_load_data_id id)
*
* Based on policy, the buffer is measured into the ima log.
*/
-void process_buffer_measurement(struct inode *inode, const void *buf,
- int buf_len, const char *eventname,
- enum ima_hooks func, int pcr,
- const char *func_data)
+
+int process_buffer_measurement(struct inode *inode, const void *buf,
+ int buf_len, const char *eventname,
+ enum ima_hooks func, int pcr,
+ const char *func_data)
{
int ret = 0;
const char *audit_cause = "ENOMEM";
@@ -759,7 +760,7 @@ void process_buffer_measurement(struct inode *inode, const
void *buf,
u32 secid;
if (!ima_policy_flag)
- return;
+ return 0;
/*
* Both LSM hooks and auxilary based buffer measurements are
@@ -773,7 +774,7 @@ void process_buffer_measurement(struct inode *inode, const
void *buf,
action = ima_get_action(inode, current_cred(), secid, 0, func,
&pcr, &template, func_data);
if (!(action & IMA_MEASURE))
- return;
+ return 0;
}
if (!pcr)
@@ -788,7 +789,7 @@ void process_buffer_measurement(struct inode *i
[PATCH 0/3] IMA: Infrastructure for measurement of critical kernel data
There are several kernel components that contain critical data which if accidentally or maliciously altered, can compromise the security of the kernel. Example of such components would include LSMs like SELinux, or AppArmor; or device-mapper targets like dm-crypt, dm-verity etc. Many of these components do not use the capabilities provided by kernel integrity subsystem (IMA), and thus they don't use the benefits of extended TPM PCR quotes and ultimately the benefits of remote attestation. This series bridges this gap, so that potential kernel components that contain data critical to the security of the kernel could take advantage of IMA's measuring and quoting abilities - thus ultimately enabling remote attestation for their specific data. System administrators may want to pick and choose which kernel components they would want to enable for measurements, quoting, and remote attestation. To enable that, a new IMA policy is introduced. And lastly, the functionality is exposed through a function ima_measure_critical_data(). The functionality is generic enough to measure the data of any kernel component at runtime. 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 This series also has a dependency on the following patch series: https://patchwork.kernel.org/patch/11709527/ Tushar Sugandhi (3): IMA: generalize keyring specific measurement constructs IMA: add policy to support measuring critical data from kernel components IMA: define IMA hook to measure critical data from kernel components Documentation/ABI/testing/ima_policy | 6 +- include/linux/ima.h | 9 ++ security/integrity/ima/ima.h | 12 +-- security/integrity/ima/ima_api.c | 8 +- security/integrity/ima/ima_main.c| 46 +++--- security/integrity/ima/ima_policy.c | 120 --- 6 files changed, 147 insertions(+), 54 deletions(-) -- 2.17.1
[PATCH 2/3] IMA: add policy to support measuring critical data from kernel components
There would be several candidate kernel components suitable for IMA
measurement. Not all of them would be enlightened for IMA measurement.
Also, system administrators may not want to measure data for all of
them, even when they are enlightened for IMA measurements. An IMA policy
specific to various kernel components is needed to measure their
respective critical data.
Add a new IMA policy CRITICAL_DATA+data_sources to support measuring
various critical kernel components. This policy would enable the
system administrators to limit the measurement to the components,
if the components are enlightened for IMA measurement.
Signed-off-by: Tushar Sugandhi
---
Documentation/ABI/testing/ima_policy | 6 +-
security/integrity/ima/ima.h | 1 +
security/integrity/ima/ima_api.c | 2 +-
security/integrity/ima/ima_policy.c | 84 ++--
4 files changed, 74 insertions(+), 19 deletions(-)
diff --git a/Documentation/ABI/testing/ima_policy
b/Documentation/ABI/testing/ima_policy
index cd572912c593..a0dd0f108555 100644
--- a/Documentation/ABI/testing/ima_policy
+++ b/Documentation/ABI/testing/ima_policy
@@ -29,7 +29,7 @@ Description:
base: 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
@@ -125,3 +125,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|apparmor|dm-crypt
diff --git a/security/integrity/ima/ima.h b/security/integrity/ima/ima.h
index e2a151d6653d..99773dfa2541 100644
--- a/security/integrity/ima/ima.h
+++ b/security/integrity/ima/ima.h
@@ -200,6 +200,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_policy.c
b/security/integrity/ima/ima_policy.c
index 4efaf8956eb8..8451ccb2a775 100644
--- a/security/integrity/ima/ima_policy.c
+++ b/security/integrity/ima/ima_policy.c
@@ -22,17 +22,18 @@
#include "ima.h"
/* flags definitions */
-#define IMA_FUNC 0x0001
-#define IMA_MASK 0x0002
-#define IMA_FSMAGIC0x0004
-#define IMA_UID0x0008
-#define IMA_FOWNER 0x0010
-#define IMA_FSUUID 0x0020
-#define IMA_INMASK 0x0040
-#define IMA_EUID 0x0080
-#define IMA_PCR0x0100
-#define IMA_FSNAME 0x0200
-#define IMA_KEYRINGS 0x0400
+#define IMA_FUNC 0x0001
+#define IMA_MASK 0x0002
+#define IMA_FSMAGIC0x0004
+#define IMA_UID0x0008
+#define IMA_FOWNER 0x0010
+#define IMA_FSUUID 0x0020
+#define IMA_INMASK 0x0040
+#define IMA_EUID 0x0080
+#define IMA_PCR0x0100
+#define IMA_FSNAME 0x0200
+#define IMA_KEYRINGS 0x0400
+#define IMA_DATA_SOURCES 0x0800
#define UNKNOWN0
#define MEASURE0x0001 /* same as IMA_MEASURE */
@@ -84,6 +85,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;
};
@@ -508,14 +510,23 @@ static bool ima_match_rules(struct ima_rule_entry *rule,
struct inode *inode,
{
int i;
- if (func == KEY_CHECK) {
- return (r
[PATCH 1/3] IMA: generalize keyring specific measurement constructs
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 without code duplication.
Refactor the keyring specific measurement constructs to be generic and
reusable in other measurement scenarios. Rename the parameter "size"
in process_buffer_measurement() to "buf_len" to indicate it is the
length of the buffer pointed by the parameter "buf".
Signed-off-by: Tushar Sugandhi
---
security/integrity/ima/ima.h| 11
security/integrity/ima/ima_api.c| 6 ++---
security/integrity/ima/ima_main.c | 17 ++--
security/integrity/ima/ima_policy.c | 40 +
4 files changed, 41 insertions(+), 33 deletions(-)
diff --git a/security/integrity/ima/ima.h b/security/integrity/ima/ima.h
index 38043074ce5e..e2a151d6653d 100644
--- a/security/integrity/ima/ima.h
+++ b/security/integrity/ima/ima.h
@@ -255,7 +255,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,
@@ -265,9 +265,10 @@ void ima_store_measurement(struct integrity_iint_cache
*iint, struct file *file,
struct evm_ima_xattr_data *xattr_value,
int xattr_len, const struct modsig *modsig, int pcr,
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);
+void process_buffer_measurement(struct inode *inode, const void *buf,
+ int buf_len, const char *eventname,
+ enum ima_hooks func, 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,
@@ -283,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 8a91711ca79b..a8740b7ea417 100644
--- a/security/integrity/ima/ima_main.c
+++ b/security/integrity/ima/ima_main.c
@@ -728,17 +728,18 @@ int ima_load_data(enum kernel_load_data_id id)
* process_buffer_measurement - Measure the buffer to ima log.
* @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 buff
Re: [PATCH v7 1/8] IMA: generalize keyring specific measurement constructs
On 2020-12-10 2:14 p.m., Tyler Hicks wrote:
On 2020-12-09 11:42:05, Tushar Sugandhi wrote:
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
I've got a few code cleanup suggestions to ima_match_rule_data() below
but the current patch is fine:
Reviewed-by: Tyler Hicks
---
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 68956e884403..e76ef4bfd0f4 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_h
Re: [PATCH v7 2/8] IMA: add support to measure buffer data hash
On 2020-12-10 2:38 p.m., Tyler Hicks wrote: On 2020-12-09 11:42:06, Tushar Sugandhi wrote: 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 --- 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 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 e76ef4bfd0f4..03aad13e9e70 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, con
Re: [PATCH v7 6/8] IMA: extend critical data hook to limit the measurement based on a label
On 2020-12-10 3:19 p.m., Tyler Hicks wrote: On 2020-12-09 11:42:10, Tushar Sugandhi wrote: 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 Reviewed-by: Tyler Hicks Tyler Thanks for the review. ~Tushar
Re: [PATCH v7 7/8] IMA: define a builtin critical data measurement policy
On 2020-12-10 3:22 p.m., Tyler Hicks wrote: On 2020-12-09 11:42:11, Tushar Sugandhi wrote: From: Lakshmi Ramasubramanian 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". Update the documentation on kernel parameters to document the new critical data builtin policy. Signed-off-by: Lakshmi Ramasubramanian Reviewed-by: Tyler Hicks Tyler Thanks for the review. ~Tushar
Re: [PATCH v7 3/8] IMA: define a hook to measure kernel integrity critical data
On 2020-12-10 3:02 p.m., Tyler Hicks wrote:
On 2020-12-09 11:42:07, Tushar Sugandhi wrote:
IMA provides capabilities to measure file data, and in-memory 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 a device. Currently,
IMA does not provide a generic function for kernel subsystems to measure
their integrity critical data.
Define a new IMA hook - ima_measure_critical_data to measure kernel
integrity critical data.
Signed-off-by: Tushar Sugandhi
---
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 ac3d82f962f2..675f54db6264 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_APPRAISE_BOOTPARAM
extern void ima_appraise_parse_cmdline(void);
@@ -122,6 +125,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 03aad13e9e70..ae59f4a4dd70 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
Re: [PATCH v7 4/8] IMA: add policy rule to measure critical data
On 2020-12-10 3:10 p.m., Tyler Hicks wrote:
On 2020-12-09 11:42:08, Tushar Sugandhi wrote:
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
---
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..9a8ee80a3128 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_FSNAME0x0200
#define IMA_KEYRINGS 0x0400
+#define IMA_DATA_SOURCE0x0800
You introduce data_source= in the next patch. This macro shouldn't be
added until the next patch.
Ok I will move IMA_DATA_SOURCE to the next patch.
#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_source; /* Measure data from this source
*/
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_source)
+ return true;
+ else
+ opt_list = rule->data_source;
If you take my suggestions on patch #1, remove the else and simply
assign opt_list here, too.
Yup. Will do.
+ 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_SOURCE) ||
+ (entry->flags & ~(IMA_FUNC | IMA_UID | IMA_PCR |
+ IMA_DATA_SOURCE)))
IMA_DATA_SOURCE shouldn't exist in this patch. This isn't the right
indentation, either. See how IMA_KEYRINGS is indented in the KEY_CHECK
case above.
Will do.
~Tushar
Tyler
+ return false;
+
+ if (ima_rule_contains_lsm_cond(entry))
+ return false;
+
break;
default:
return false;
--
2.17.1
Re: [PATCH v7 5/8] IMA: limit critical data measurement based on a label
On 2020-12-10 3:15 p.m., Tyler Hicks wrote:
On 2020-12-09 11:42:09, Tushar Sugandhi wrote:
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 based on
a label for the given subsystems.
Add a new IMA policy condition - "data_source:=" 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 labels listed in "data_source:=".
Limit the measurement to the labels that are specified in the IMA
policy - CRITICAL_DATA+"data_source:=". 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
This patch will look good once all the IMA_DATA_SOURCE stuff is moved
over from patch #4.
Tyler
Sounds good. Will do.
~Tushar
---
Documentation/ABI/testing/ima_policy | 2 ++
security/integrity/ima/ima_policy.c | 26 +-
2 files changed, 27 insertions(+), 1 deletion(-)
diff --git a/Documentation/ABI/testing/ima_policy
b/Documentation/ABI/testing/ima_policy
index 6ec7daa87cba..0f4ee9e0a455 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
+ data_source:= [label]
+ 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 9a8ee80a3128..7486d09a3f60 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_source, 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_source, "data_source=%s"},
{Opt_err, NULL}
};
@@ -1350,6 +1351,23 @@ static int ima_parse_rule(char *rule, struct ima_rule_entry *entry)
entry->flags |= IMA_KEYRINGS;
break;
+ case Opt_data_source:
+ ima_log_string(ab, "data_source", args[0].from);
+
+ if (entry->data_source) {
+ result = -EINVAL;
+ break;
+ }
+
+ entry->data_source = ima_alloc_rule_opt_list(args);
+ if (IS_ERR(entry->data_source)) {
+ result = PTR_ERR(entry->data_source);
+ entry->data_source = NULL;
+ break;
+ }
+
+ entry->flags |= IMA_DATA_SOURCE;
+ break;
case Opt_fsuuid:
ima_log_string(ab, "fsuuid", args[0].from);
@@ -1730,6 +1748,12 @@ int ima_policy_show(struct seq_file *m, void *v)
seq_puts(m, " ");
}
+ if (entry->flags & IMA_DATA_SOURCE) {
+ seq_puts(m, "data_source=");
+ ima_show_rule_opt_list(m, entry->data_source);
+ 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
Re: [PATCH v7 3/8] IMA: define a hook to measure kernel integrity critical data
+ */
+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__);
This is a problem for the developer making use of the
ima_measure_critical_data() API and shouldn't be logged, IMO, because a
user/admin can do nothing about it. I think the error message should be
dropped.
Thanks Tyler.
Will drop the message.
[PATCH v8 1/8] IMA: generalize keyring specific measurement constructs
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
Reviewed-by: Tyler Hicks
---
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 | 46 ++---
4 files changed, 37 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 68956e884403..e76ef4bfd0f4 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_measuremen
[PATCH v8 0/8] IMA: support for measuring kernel integrity critical data
cy 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 | 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 | 118 ++ security/integrity/ima/ima_queue_keys.c | 3 +- security/selinux/Makefile | 2 + security/selinux/include/security.h | 11 +- security/selinux/measure.c| 81 security/selinux/ss/services.c| 71 +-- 14 files changed, 354 insertions(+), 51 deletions(-) create mode 100644 security/selinux/measure.c -- 2.17.1
[PATCH v8 5/8] IMA: limit critical data measurement based on a label
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 based on
a label for the given subsystems.
Add a new IMA policy condition - "data_source:=" 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 labels listed in "data_source:=".
Limit the measurement to the labels that are specified in the IMA
policy - CRITICAL_DATA+"data_source:=". 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
---
Documentation/ABI/testing/ima_policy | 2 ++
security/integrity/ima/ima_policy.c | 30 ++--
2 files changed, 30 insertions(+), 2 deletions(-)
diff --git a/Documentation/ABI/testing/ima_policy
b/Documentation/ABI/testing/ima_policy
index 6ec7daa87cba..0f4ee9e0a455 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
+ data_source:= [label]
+ 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 07116ff35c25..fea996a9e26c 100644
--- a/security/integrity/ima/ima_policy.c
+++ b/security/integrity/ima/ima_policy.c
@@ -34,6 +34,7 @@
#define IMA_PCR0x0100
#define IMA_FSNAME 0x0200
#define IMA_KEYRINGS 0x0400
+#define IMA_DATA_SOURCE0x0800
#define UNKNOWN0
#define MEASURE0x0001 /* same as IMA_MEASURE */
@@ -930,7 +931,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_source, Opt_err
};
static const match_table_t policy_tokens = {
@@ -967,6 +968,7 @@ static const match_table_t policy_tokens = {
{Opt_pcr, "pcr=%s"},
{Opt_template, "template=%s"},
{Opt_keyrings, "keyrings=%s"},
+ {Opt_data_source, "data_source=%s"},
{Opt_err, NULL}
};
@@ -1134,7 +1136,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_DATA_SOURCE))
return false;
if (ima_rule_contains_lsm_cond(entry))
@@ -1344,6 +1347,23 @@ static int ima_parse_rule(char *rule, struct
ima_rule_entry *entry)
entry->flags |= IMA_KEYRINGS;
break;
+ case Opt_data_source:
+ ima_log_string(ab, "data_source", args[0].from);
+
+ if (entry->data_source) {
+ result = -EINVAL;
+ break;
+ }
+
+ entry->data_source = ima_alloc_rule_opt_list(args);
+ if (IS_ERR(entry->data_source)) {
+ result = PTR_ERR(entry->data_source);
+ entry->data_source = NULL;
+ break;
+ }
+
+ entry->flags |= IMA_DATA_SOURCE;
+ break;
case Opt_fsuuid:
ima_log_string(ab, "fsuuid", args[0].from);
@@ -1724,6 +1744,12 @@ int ima_policy_show(struct seq_file *m, void *v)
seq_puts(m, " ");
}
+ if (entry->flags & IMA_DATA_SOURCE) {
+ seq_puts(m, "data_source=");
+ ima_show_rule_opt_list(m, entry->data_source);
+ 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
[PATCH v8 6/8] IMA: extend critical data hook to limit the measurement based on a label
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
Reviewed-by: Tyler Hicks
---
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 675f54db6264..6434287a81cd 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);
@@ -125,7 +126,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 dff4bce4fb09..cc828ba00790 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 various data structures,
* policies, and states stored in kernel memory that can impact the integrity
@@ -944,15 +948,16 @@ 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)
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
[PATCH v8 2/8] IMA: add support to measure buffer data hash
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 --- 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| 38 +--- security/integrity/ima/ima_queue_keys.c | 3 +- 5 files changed, 39 insertions(+), 9 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 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 e76ef4bfd0f4..0f8409d77602 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) +
[PATCH v8 3/8] IMA: define a hook to measure kernel integrity critical data
IMA provides capabilities to measure file data, and in-memory 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 a device. Currently,
IMA does not provide a generic function for kernel subsystems to measure
their integrity critical data.
Define a new IMA hook - ima_measure_critical_data to measure kernel
integrity critical data.
Signed-off-by: Tushar Sugandhi
---
include/linux/ima.h | 6 ++
security/integrity/ima/ima.h | 1 +
security/integrity/ima/ima_api.c | 2 +-
security/integrity/ima/ima_main.c | 34 +++
4 files changed, 42 insertions(+), 1 deletion(-)
diff --git a/include/linux/ima.h b/include/linux/ima.h
index ac3d82f962f2..675f54db6264 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_APPRAISE_BOOTPARAM
extern void ima_appraise_parse_cmdline(void);
@@ -122,6 +125,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 0f8409d77602..dff4bce4fb09 100644
--- a/security/integrity/ima/ima_main.c
+++ b/security/integrity/ima/ima_main.c
@@ -922,6 +922,40 @@ 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 various data structures,
+ * policies, and states stored in kernel memory that can impact the integrity
+ * of the system.
+ *
+ * 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)
+ 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;
--
2.17.1
[PATCH v8 4/8] IMA: add policy rule to measure critical data
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
---
Documentation/ABI/testing/ima_policy | 2 +-
security/integrity/ima/ima_policy.c | 34
2 files changed, 31 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 a09d1a41a290..07116ff35c25 100644
--- a/security/integrity/ima/ima_policy.c
+++ b/security/integrity/ima/ima_policy.c
@@ -85,6 +85,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_source; /* Measure data from this source
*/
struct ima_template_desc *template;
};
@@ -479,6 +480,12 @@ static bool ima_match_rule_data(struct ima_rule_entry
*rule,
opt_list = rule->keyrings;
break;
+ case CRITICAL_DATA:
+ if (!rule->data_source)
+ return true;
+
+ opt_list = rule->data_source;
+ break;
default:
return false;
}
@@ -515,13 +522,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;
@@ -1116,6 +1129,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;
@@ -1248,6 +1272,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
[PATCH v8 8/8] selinux: include a consumer of the new IMA critical data hook
From: Lakshmi Ramasubramanian
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.
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_source=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
Suggested-by: Stephen Smalley
---
Documentation/ABI/testing/ima_policy | 3 +-
security/selinux/Makefile| 2 +
security/selinux/include/security.h | 11 +++-
security/selinux/measure.c | 81
security/selinux/ss/services.c | 71
5 files changed, 157 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 0f4ee9e0a455..7c7023f7986b 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
- data_source:= [label]
+ data_source:= [selinux]|[label]
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..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/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 ..a070d8dae403
--- /dev/null
+++ b/security/selinux/measure.c
@@ -0,0 +1,81 @@
+// SPDX-License-Identifier: GPL-2.0-or-later
+/*
+ * Measure SELinux state using IMA subsystem.
+ */
+#include
+#include
+#include
+#include "security.h"
+
+/*
+ * This function creates a unique name by appending the timestamp to
+ * the given string.
[PATCH v8 7/8] IMA: define a builtin critical data measurement policy
From: Lakshmi Ramasubramanian
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".
Update the documentation on kernel parameters to document
the new critical data builtin policy.
Signed-off-by: Lakshmi Ramasubramanian
Reviewed-by: Tyler Hicks
---
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 fea996a9e26c..376b625acc72 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
@@ -872,6 +879,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
Re: [PATCH v8 4/8] IMA: add policy rule to measure critical data
On 2020-12-11 4:25 p.m., Tyler Hicks wrote:
On 2020-12-11 15:58:03, Tushar Sugandhi wrote:
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
---
Documentation/ABI/testing/ima_policy | 2 +-
security/integrity/ima/ima_policy.c | 34
2 files changed, 31 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 a09d1a41a290..07116ff35c25 100644
--- a/security/integrity/ima/ima_policy.c
+++ b/security/integrity/ima/ima_policy.c
@@ -85,6 +85,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_source; /* Measure data from this source
*/
Argh, there are still some more instances of data_source sneaking into
this patch too early instead of waiting until the next patch.
I kept it purposefully in this patch so that the
"case CRITICAL_DATA:" could be properly defined.
Also, my impression was rule->data_source is not part of the user facing
policy.
Whereas IMA_DATA_SOURCE, Opt_data_source, data_source=%s are.
That's why they are part of Patch #5.
Patch #5 IMA: limit critical data measurement based on a label
struct ima_template_desc *template;
};
@@ -479,6 +480,12 @@ static bool ima_match_rule_data(struct ima_rule_entry *rule,
opt_list = rule->keyrings;
break;
+ case CRITICAL_DATA:
+ if (!rule->data_source)
+ return true;
+
+ opt_list = rule->data_source;
+ break;
I guess this case should unconditionally return true in this patch and
then the include this additional logic in the next patch.
Sorry, I missed these on my last review.
No worries.
As I mentioned above, I kept it purposefully in this patch since
my impression was rule->data_source is not part of the user facing
policy.
But I can simply return true here as you suggested, and move the logic
to the next patch.
+ case CRITICAL_DATA:
+ if (!rule->data_source)
+ return true;
+
+ opt_list = rule->data_source;
+ break;
~Tushar
Re: [PATCH v8 4/8] IMA: add policy rule to measure critical data
+ case CRITICAL_DATA: + if (!rule->data_source) + return true; + + opt_list = rule->data_source; + break; I guess this case should unconditionally return true in this patch and then the include this additional logic in the next patch. Sorry, I missed these on my last review. No worries. As I mentioned above, I kept it purposefully in this patch since my impression was rule->data_source is not part of the user facing policy. But I can simply return true here as you suggested, and move the logic to the next patch. I understand the thinking that it isn't harmful in this patch but I think it is a bit cleaner to introduce the data_source policy language element and all of its backend support in the same patch. Please move it to the next patch. Thanks! Tyler Will do. Thanks a lot Tyler for a detailed review. Appreciate it. ~Tushar
[PATCH v9 1/8] IMA: generalize keyring specific measurement constructs
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
Reviewed-by: Tyler Hicks
---
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 | 46 ++---
4 files changed, 37 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 68956e884403..e76ef4bfd0f4 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_measuremen
[PATCH v9 6/8] IMA: extend critical data hook to limit the measurement based on a label
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
Reviewed-by: Tyler Hicks
---
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 675f54db6264..6434287a81cd 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);
@@ -125,7 +126,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 dff4bce4fb09..cc828ba00790 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 various data structures,
* policies, and states stored in kernel memory that can impact the integrity
@@ -944,15 +948,16 @@ 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)
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
[PATCH v9 5/8] IMA: limit critical data measurement based on a label
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 based on
a label for the given subsystems.
Add a new IMA policy condition - "data_source:=" 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 labels listed in "data_source:=".
Limit the measurement to the labels that are specified in the IMA
policy - CRITICAL_DATA+"data_source:=". 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
---
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..0f4ee9e0a455 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
+ data_source:= [label]
+ 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 d45c2dbb6d45..fea996a9e26c 100644
--- a/security/integrity/ima/ima_policy.c
+++ b/security/integrity/ima/ima_policy.c
@@ -34,6 +34,7 @@
#define IMA_PCR0x0100
#define IMA_FSNAME 0x0200
#define IMA_KEYRINGS 0x0400
+#define IMA_DATA_SOURCE0x0800
#define UNKNOWN0
#define MEASURE0x0001 /* 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_source; /* Measure data from this source
*/
struct ima_template_desc *template;
};
@@ -480,7 +482,11 @@ static bool ima_match_rule_data(struct ima_rule_entry
*rule,
opt_list = rule->keyrings;
break;
case CRITICAL_DATA:
- return true;
+ if (!rule->data_source)
+ return true;
+
+ opt_list = rule->data_source;
+ break;
default:
return false;
}
@@ -925,7 +931,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_source, Opt_err
};
static const match_table_t policy_tokens = {
@@ -962,6 +968,7 @@ static const match_table_t policy_tokens = {
{Opt_pcr, "pcr=%s"},
{Opt_template, "template=%s"},
{Opt_keyrings, "keyrings=%s"},
+ {Opt_data_source, "data_source=%s"},
{Opt_err, NULL}
};
@@ -1129,7 +1136,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_DATA_SOURCE))
return false;
if (ima_rule_contains_lsm_cond(entry))
@@ -1339,6 +1347,23 @@ static int ima_parse_rule(char *rule, struct
ima_rule_entry *entry)
entry->flags |= IMA_KEYRINGS;
break;
+ case Opt_data_source:
+ ima_log_string(ab, "data_source", args[0].from);
+
+ if (entry->data_source) {
+ result = -EINVAL;
+ break;
+ }
+
+ entry->data_source = ima_alloc_rule_opt_list(args);
+ if (IS_ERR(entry->data_source)) {
+ result = PTR_ERR(entry->data_source);
+ entry->data_source = NULL;
+ break;
+ }
+
+ entry->flags |= IMA_DATA_SOURCE;
+ break;
case Opt_fsuuid:
ima_log_string(ab, &quo
[PATCH v9 2/8] IMA: add support to measure buffer data hash
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 Reviewed-by: Tyler Hicks --- 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| 38 +--- security/integrity/ima/ima_queue_keys.c | 3 +- 5 files changed, 39 insertions(+), 9 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 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 e76ef4bfd0f4..0f8409d77602 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_da
[PATCH v9 0/8] IMA: support for measuring kernel integrity critical data
dded 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 | 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 | 118 ++ security/integrity/ima/ima_queue_keys.c | 3 +- security/selinux/Makefile | 2 + security/selinux/include/security.h | 11 +- security/selinux/measure.c| 79 security/selinux/ss/services.c| 71 +-- 14 files changed, 352 insertions(+), 51 deletions(-) create mode 100644 security/selinux/measure.c -- 2.17.1
[PATCH v9 7/8] IMA: define a builtin critical data measurement policy
From: Lakshmi Ramasubramanian
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".
Update the documentation on kernel parameters to document
the new critical data builtin policy.
Signed-off-by: Lakshmi Ramasubramanian
Reviewed-by: Tyler Hicks
---
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 fea996a9e26c..376b625acc72 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
@@ -872,6 +879,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
[PATCH v9 8/8] selinux: include a consumer of the new IMA critical data hook
From: Lakshmi Ramasubramanian
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.
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_source=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
Suggested-by: Stephen Smalley
Reviewed-by: Tyler Hicks
---
Documentation/ABI/testing/ima_policy | 3 +-
security/selinux/Makefile| 2 +
security/selinux/include/security.h | 11 +++-
security/selinux/measure.c | 79
security/selinux/ss/services.c | 71 +
5 files changed, 155 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 0f4ee9e0a455..7c7023f7986b 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
- data_source:= [label]
+ data_source:= [selinux]|[label]
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..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/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 ..b7e24358e11d
--- /dev/null
+++ b/security/selinux/measure.c
@@ -0,0 +1,79 @@
+// SPDX-License-Identifier: GPL-2.0-or-later
+/*
+ * Measure SELinux state using IMA subsystem.
+ */
+#include
+#include
+#include
+#include "security.h"
+
+/*
+ * This function creates a unique name by appending the timestam
[PATCH v9 3/8] IMA: define a hook to measure kernel integrity critical data
IMA provides capabilities to measure file data, and in-memory 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 a device. Currently,
IMA does not provide a generic function for kernel subsystems to measure
their integrity critical data.
Define a new IMA hook - ima_measure_critical_data to measure kernel
integrity critical data.
Signed-off-by: Tushar Sugandhi
Reviewed-by: Tyler Hicks
---
include/linux/ima.h | 6 ++
security/integrity/ima/ima.h | 1 +
security/integrity/ima/ima_api.c | 2 +-
security/integrity/ima/ima_main.c | 34 +++
4 files changed, 42 insertions(+), 1 deletion(-)
diff --git a/include/linux/ima.h b/include/linux/ima.h
index ac3d82f962f2..675f54db6264 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_APPRAISE_BOOTPARAM
extern void ima_appraise_parse_cmdline(void);
@@ -122,6 +125,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 0f8409d77602..dff4bce4fb09 100644
--- a/security/integrity/ima/ima_main.c
+++ b/security/integrity/ima/ima_main.c
@@ -922,6 +922,40 @@ 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 various data structures,
+ * policies, and states stored in kernel memory that can impact the integrity
+ * of the system.
+ *
+ * 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)
+ 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;
--
2.17.1
[PATCH v9 4/8] IMA: add policy rule to measure critical data
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
---
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 a09d1a41a290..d45c2dbb6d45 100644
--- a/security/integrity/ima/ima_policy.c
+++ b/security/integrity/ima/ima_policy.c
@@ -479,6 +479,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;
}
@@ -515,13 +517,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;
@@ -1116,6 +1124,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;
@@ -1248,6 +1267,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
Re: [PATCH v9 4/8] IMA: add policy rule to measure critical data
On 2020-12-12 11:20 a.m., Tyler Hicks wrote: On 2020-12-12 10:02:47, Tushar Sugandhi wrote: 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 This looks nice. Thanks for the changes! Reviewed-by: Tyler Hicks Tyler Thanks for the detailed review on this series Tyler. We really appreciate it. ~Tushar
Re: [PATCH v9 5/8] IMA: limit critical data measurement based on a label
On 2020-12-12 11:20 a.m., Tyler Hicks wrote: On 2020-12-12 10:02:48, Tushar Sugandhi wrote: 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 based on a label for the given subsystems. Add a new IMA policy condition - "data_source:=" 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 labels listed in "data_source:=". Limit the measurement to the labels that are specified in the IMA policy - CRITICAL_DATA+"data_source:=". 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 Reviewed-by: Tyler Hicks Tyler Thanks again Tyler. ~Tushar
[PATCH v10 2/8] IMA: add support to measure buffer data hash
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
Reviewed-by: Tyler Hicks
---
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) {
+
[PATCH v10 0/8] IMA: support for measuring kernel integrity critical data
tical_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
[PATCH v10 4/8] IMA: add policy rule to measure critical data
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
Reviewed-by: Tyler Hicks
Reviewed-by: Mimi Zohar
---
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
[PATCH v10 3/8] IMA: define a hook to measure kernel integrity critical data
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
Reviewed-by: Tyler Hicks
---
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
[PATCH v10 6/8] IMA: extend critical data hook to limit the measurement based on a label
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
Reviewed-by: Tyler Hicks
---
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
[PATCH v10 1/8] IMA: generalize keyring specific measurement constructs
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
Reviewed-by: Tyler Hicks
---
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
[PATCH v10 7/8] IMA: define a builtin critical data measurement policy
From: Lakshmi Ramasubramanian
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
Reviewed-by: Tyler Hicks
Reviewed-by: Mimi Zohar
---
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
[PATCH v10 8/8] selinux: include a consumer of the new IMA critical data hook
From: Lakshmi Ramasubramanian
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
Suggested-by: Stephen Smalley
Reviewed-by: Tyler Hicks
---
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 ..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 (nra...@linux.microsoft.com)
+ *
+ * Measure critical data structures maintainted by SELinux
+ * using IMA subsystem.
+ */
+#include
+#include
+#include
+#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
[PATCH v10 5/8] IMA: limit critical data measurement based on a label
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
Reviewed-by: Tyler Hicks
---
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_PCR0x0100
#define IMA_FSNAME 0x0200
#define IMA_KEYRINGS 0x0400
+#define IMA_LABEL 0x0800
#define UNKNOWN0
#define MEASURE0x0001 /* 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) {
+
Re: [PATCH v10 5/8] IMA: limit critical data measurement based on a label
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 Reviewed-by: Tyler Hicks This is looking a lot better. thanks, Mimi Thanks a lot for the feedback Mimi. Appreciate it. :) ~Tushar
[PATCH v7 2/8] IMA: add support to measure buffer data hash
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 --- 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 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 e76ef4bfd0f4..03aad13e9e70 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) +
[PATCH v7 7/8] IMA: define a builtin critical data measurement policy
From: Lakshmi Ramasubramanian
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".
Update the documentation on kernel parameters to document
the new critical data builtin policy.
Signed-off-by: Lakshmi Ramasubramanian
---
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 7486d09a3f60..37ca16a9e65f 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
@@ -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
[PATCH v7 8/8] selinux: include a consumer of the new IMA critical data hook
From: Lakshmi Ramasubramanian 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. Various data structures, policies and states stored in kernel memory also impact the integrity of the system. Updates to these data structures would have an impact on the security functionalities. For example, SELinux stores the active policy in memory. Changes to this 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 policy is a critical data for this security module that needs to be measured. This measurement can be used by an attestation service, for instance, to verify if the policy has been setup correctly and that it hasn't been tampered at run-time. 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. 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_source=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 Suggested-by: Stephen Smalley --- Documentation/ABI/testing/ima_policy | 3 +- security/selinux/Makefile| 2 + security/selinux/include/security.h | 11 +++- security/selinux/measure.c | 86 security/selinux/ss/services.c | 71 --- 5 files changed, 162 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 0f4ee9e0a455..7c7023f7986b 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 - data_source:= [label] + data_source:= [selinux]|[label] 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..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/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_sidt
[PATCH v7 6/8] IMA: extend critical data hook to limit the measurement based on a label
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
---
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 675f54db6264..6434287a81cd 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);
@@ -125,7 +126,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 ae59f4a4dd70..7c633901f441 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
[PATCH v7 5/8] IMA: limit critical data measurement based on a label
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 based on
a label for the given subsystems.
Add a new IMA policy condition - "data_source:=" 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 labels listed in "data_source:=".
Limit the measurement to the labels that are specified in the IMA
policy - CRITICAL_DATA+"data_source:=". 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
---
Documentation/ABI/testing/ima_policy | 2 ++
security/integrity/ima/ima_policy.c | 26 +-
2 files changed, 27 insertions(+), 1 deletion(-)
diff --git a/Documentation/ABI/testing/ima_policy
b/Documentation/ABI/testing/ima_policy
index 6ec7daa87cba..0f4ee9e0a455 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
+ data_source:= [label]
+ 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 9a8ee80a3128..7486d09a3f60 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_source, 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_source, "data_source=%s"},
{Opt_err, NULL}
};
@@ -1350,6 +1351,23 @@ static int ima_parse_rule(char *rule, struct
ima_rule_entry *entry)
entry->flags |= IMA_KEYRINGS;
break;
+ case Opt_data_source:
+ ima_log_string(ab, "data_source", args[0].from);
+
+ if (entry->data_source) {
+ result = -EINVAL;
+ break;
+ }
+
+ entry->data_source = ima_alloc_rule_opt_list(args);
+ if (IS_ERR(entry->data_source)) {
+ result = PTR_ERR(entry->data_source);
+ entry->data_source = NULL;
+ break;
+ }
+
+ entry->flags |= IMA_DATA_SOURCE;
+ break;
case Opt_fsuuid:
ima_log_string(ab, "fsuuid", args[0].from);
@@ -1730,6 +1748,12 @@ int ima_policy_show(struct seq_file *m, void *v)
seq_puts(m, " ");
}
+ if (entry->flags & IMA_DATA_SOURCE) {
+ seq_puts(m, "data_source=");
+ ima_show_rule_opt_list(m, entry->data_source);
+ 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
[PATCH v7 4/8] IMA: add policy rule to measure critical data
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
---
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..9a8ee80a3128 100644
--- a/security/integrity/ima/ima_policy.c
+++ b/security/integrity/ima/ima_policy.c
@@ -34,6 +34,7 @@
#define IMA_PCR0x0100
#define IMA_FSNAME 0x0200
#define IMA_KEYRINGS 0x0400
+#define IMA_DATA_SOURCE0x0800
#define UNKNOWN0
#define MEASURE0x0001 /* 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_source; /* Measure data from this source
*/
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_source)
+ return true;
+ else
+ opt_list = rule->data_source;
+ 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_SOURCE) ||
+ (entry->flags & ~(IMA_FUNC | IMA_UID | IMA_PCR |
+ IMA_DATA_SOURCE)))
+ return false;
+
+ if (ima_rule_contains_lsm_cond(entry))
+ return false;
+
break;
default:
return false;
--
2.17.1
[PATCH v7 1/8] IMA: generalize keyring specific measurement constructs
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
---
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 68956e884403..e76ef4bfd0f4 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
[PATCH v7 3/8] IMA: define a hook to measure kernel integrity critical data
IMA provides capabilities to measure file data, and in-memory 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 a device. Currently,
IMA does not provide a generic function for kernel subsystems to measure
their integrity critical data.
Define a new IMA hook - ima_measure_critical_data to measure kernel
integrity critical data.
Signed-off-by: Tushar Sugandhi
---
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 ac3d82f962f2..675f54db6264 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_APPRAISE_BOOTPARAM
extern void ima_appraise_parse_cmdline(void);
@@ -122,6 +125,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 03aad13e9e70..ae59f4a4dd70 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
[PATCH v7 0/8] IMA: support for measuring kernel integrity critical data
_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 | 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 | 122 ++ security/integrity/ima/ima_queue_keys.c | 3 +- security/selinux/Makefile | 2 + security/selinux/include/security.h | 11 +- security/selinux/measure.c| 86 security/selinux/ss/services.c| 71 -- 14 files changed, 364 insertions(+), 50 deletions(-) create mode 100644 security/selinux/measure.c -- 2.17.1
[PATCH v6 0/8] IMA: support for measuring kernel 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.
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_que
[PATCH v6 6/8] IMA: add support to critical data hook to limit data sources for measurement
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
---
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
[PATCH v6 3/8] IMA: define a hook to measure kernel integrity critical data
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
---
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
[PATCH v6 4/8] IMA: add policy rule to measure critical data
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
---
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_PCR0x0100
#define IMA_FSNAME 0x0200
#define IMA_KEYRINGS 0x0400
+#define IMA_DATA_SOURCES 0x0800
#define UNKNOWN0
#define MEASURE0x0001 /* 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
[PATCH v6 5/8] IMA: extend policy to add data sources as a critical data measurement constraint
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
---
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
[PATCH v6 8/8] selinux: measure state and hash of the policy using IMA
From: Lakshmi Ramasubramanian 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 Suggested-by: Stephen Smalley --- Documentation/ABI/testing/ima_policy | 6 +- security/selinux/Makefile| 2 + security/selinux/hooks.c | 3 + security/selinux/include/security.h | 11 +- security/selin
[PATCH v6 2/8] IMA: add support to measure buffer data hash
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 --- 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) +
[PATCH v6 7/8] IMA: add a built-in policy rule for critical data measurement
From: Lakshmi Ramasubramanian
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
---
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
[PATCH v6 1/8] IMA: generalize keyring specific measurement constructs
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
---
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
Re: [PATCH v6 8/8] selinux: measure state and hash of the policy using IMA
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
Re: [PATCH v10 0/8] IMA: support for measuring kernel integrity critical data
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
Re: [PATCH v9 1/8] IMA: generalize keyring specific measurement constructs
Hello Mimi,
Sorry for the late response. I was on vacation last week.
On 2020-12-24 5:06 a.m., Mimi Zohar wrote:
On Sat, 2020-12-12 at 10:02 -0800, Tushar Sugandhi wrote:
diff --git a/security/integrity/ima/ima_main.c
b/security/integrity/ima/ima_main.c
index 68956e884403..e76ef4bfd0f4 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.
This can be simplified to "func specific data, may be NULL". Please
update in all places.
Ok, will do.
*
* 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..a09d1a41a290 100644
--- a/security/integrity/ima/ima_policy.c
+++ b/security/integrity/ima/ima_policy.c
@@ -453,30 +453,41 @@ 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
After the function_name is a brief description of the function, which
should not span multiple lines. Refer to Documentation/doc-
guide/kernel-doc.rst for details.
Please trim the function description to:
determine whether func_data matches the policy rule
Thanks, will do.
+ * @rule: IMA policy rule
This patch should be limited to renaming "keyring" to "func_data". It
shouldn't make other changes, even simple ones like this.
Agreed. I will revert the rule description to the old one.
+ * @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 +504,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.
Update as previously suggested.
Yes.
*
* Returns true on rule match, false on failure.
*/
static bool ima_match_rules(struct ima_rule_e
Re: [PATCH v9 2/8] IMA: add support to measure buffer data hash
On 2020-12-23 4:03 p.m., Mimi Zohar wrote: On Sat, 2020-12-12 at 10:02 -0800, Tushar Sugandhi wrote: 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. By definition, buffer data is only measured. Nothing new is added by the above paragraph. Please remove it. Sure. Will remove. Introduce a boolean parameter measure_buf_hash to support measuring hash of a buffer, which would be much smaller, instead of the buffer itself. Like the patch Subject line use "the buffer data hash" instead of the "hash of a buffer". Will do. There's no need to include the boolean parameter name "measure_buf_hash". Please remove it. Will do. Signed-off-by: Tushar Sugandhi Reviewed-by: Tyler Hicks --- 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| 38 +--- security/integrity/ima/ima_queue_keys.c | 3 +- 5 files changed, 39 insertions(+), 9 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); Please abbreviate the boolean name to "hash". The test would then be "if (hash == true)" or "if (hash)". Will do. 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 e76ef4bfd0f4..0f8409d77602 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 ^@hash: measure buffer data hash Agreed. W
Re: [PATCH v9 3/8] IMA: define a hook to measure kernel integrity critical data
On 2020-12-24 5:04 a.m., Mimi Zohar wrote:
On Sat, 2020-12-12 at 10:02 -0800, Tushar Sugandhi wrote:
IMA provides capabilities to measure file data, and in-memory buffer
No need for the comma here.
Up to this patch set, all the patches refer to "buffer data", not "in-
memory buffer data". This patch introduces the concept of measuring
"in-memory buffer data". Please remove "in-memory" above.
Will update the description accordingly.
data. However, various data structures, policies, and states
Here and everywhere else, there are two blanks after a period.
I checked this patch file in multiple text editors, but couldn’t find
any instance of period followed by two spaces. I will double check again
all the patches for multiple spaces, and remove them if any.
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 a device. Currently,
^integrity of the system.
Will do.
IMA does not provide a generic function for kernel subsystems to measure
their integrity critical data.
The emphasis should not be on "kernel subsystems". Simplify to "for
measuring kernel integrity critical data".
Will do.
Define a new IMA hook - ima_measure_critical_data to measure kernel
integrity critical data.
Either "ima_measure_critical_data" is between hyphens or without any
hyphens. If not hyphenated, then you could say "named
ima_measure_critical_data", but "named" isn't necessary. Or reverse "a
new IMA hook" and "ima_measure_critical_data", adding comma's like:
Define ima_measure_critical_data, a new IMA hook, to ...
Any of the above options work, just not a single hyphen.
Thanks for the suggestion.
I will use “Define ima_measure_critical_data, a new IMA hook, to ...”
Signed-off-by: Tushar Sugandhi
Reviewed-by: Tyler Hicks
---
diff --git a/security/integrity/ima/ima_main.c
b/security/integrity/ima/ima_main.c
index 0f8409d77602..dff4bce4fb09 100644
--- a/security/integrity/ima/ima_main.c
+++ b/security/integrity/ima/ima_main.c
@@ -922,6 +922,40 @@ 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
Why future tense?
I simply used the description from p_b_m()
* @eventname: event name to be used for the buffer entry.
By "buffer entry" do you mean a record in the IMA
measurement list?
Yes, a record in the IMA measurement list.
Will remove the future tense and reword it to something like:
* @event_name: event name for the buffer measurement entry
-or-
* @event_name: event name for the record in the IMA measurement list
+ * @buf: pointer to buffer containing data to measure
^pointer to buffer data
will do.
+ * @buf_len: length of buffer(in bytes)
^length of buffer data (in bytes)
will do.
+ * @measure_buf_hash: measure buffer hash
As requested in 2/8, please abbreviate the boolean name to "hash".
Refer to section "4) Naming" in Documentation/process/coding-style.rst
for variable naming conventions.
^@hash: measure buffer data hash
Sounds good. Will do.
+ *
+ * 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 various data structures,
+ * policies, and states stored in kernel memory that can impact the integrity
+ * of the system.
+ *
+ * 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.
The "/**" is the start of kernel-doc. Have you seen anywhere else in
My impression was the hooks in ima_main.c e.g. ima_file_free()
ima_file_mmap() required the double-asterisk ("/**"), and internal
functions like ima_rdwr_violation_check() require a single-asterisk
("/*")
kernel-doc.rst suggest the double-asterisk ("/**") for function comment
as well.
Function documentation
--
The general format of a function and function-like macro kernel-doc
comment is::
/**
* function_name() - Brief description of function.
Please let me know if you still want me to remove the double-asterisk
("/**") here.
the kernel using the @ in the longer function
description? Have you seen this style of longer function
description? Refer to Documentation/doc-guide/kernel-doc.rst and other
code for examples.
Thanks. I will remove the prefix "@" from in the longer
Re: [PATCH v9 4/8] IMA: add policy rule to measure critical data
On 2020-12-24 5:48 a.m., Mimi Zohar wrote: Hi Tushar, Please update the Subject line as, "Add policy rule support for measuring critical data". On Sat, 2020-12-12 at 10:02 -0800, Tushar Sugandhi wrote: 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 This patch does not restrict measuring critical data, but adds policy rule support for measuring critical data. please update the patch description accordingly. Will do. Will update the patch description accordingly. Other than that, Reviewed-by: Mimi Zohar Thanks a lot for the Reviewed-by tag. :)
Re: [PATCH v9 3/8] IMA: define a hook to measure kernel integrity critical data
On 2021-01-05 12:16 p.m., Mimi Zohar wrote:
On Tue, 2021-01-05 at 12:01 -0800, Tushar Sugandhi wrote:
data. However, various data structures, policies, and states
Here and everywhere else, there are two blanks after a period.
I checked this patch file in multiple text editors, but couldn’t find
any instance of period followed by two spaces. I will double check again
all the patches for multiple spaces, and remove them if any.
There should be two blanks after a period, not one blank.
+ *
+ * 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 various data structures,
+ * policies, and states stored in kernel memory that can impact the integrity
+ * of the system.
+ *
+ * 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.
The "/**" is the start of kernel-doc. Have you seen anywhere else in
My impression was the hooks in ima_main.c e.g. ima_file_free()
ima_file_mmap() required the double-asterisk ("/**"), and internal
functions like ima_rdwr_violation_check() require a single-asterisk
("/*")
kernel-doc.rst suggest the double-asterisk ("/**") for function comment
as well.
Function documentation
--
The general format of a function and function-like macro kernel-doc
comment is::
/**
* function_name() - Brief description of function.
Please let me know if you still want me to remove the double-asterisk
("/**") here.
Yes, of course this needs to be kernel-doc and requires "/**"
Thanks for confirming.
the kernel using the @ in the longer function
description? Have you seen this style of longer function
description? Refer to Documentation/doc-guide/kernel-doc.rst and other
code for examples.
Thanks. I will remove the prefix "@" from in the longer
function description.
Removing the @ isn't sufficient. Please look at other
examples of longer function definitions before reposting.
Yes. Agreed. I will go as per the guidance in kernel-doc.rst
Thanks again,
Tushar
thanks,
Mimi
Re: [PATCH v9 5/8] IMA: limit critical data measurement based on a label
On 2020-12-24 6:29 a.m., Mimi Zohar wrote: Hi Tushar, On Sat, 2020-12-12 at 10:02 -0800, Tushar Sugandhi wrote: 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 based on a label for the given subsystems. Restricting which kernel integrity critical data is measured is not only of interest to system administrators. Why single them out? system administrators are usually responsible for system policies/configurations.They own modifications in the config files like ima-policy. That's why we wanted to address them to begin with. But you are correct. This is not only of interest to sysadmins. I will make the description more generic. Limiting which critical data is measured is based on a label, making it flexible. In your use case scenario, you're grouping the label based on kernel subsystem, but is that really necessary? In the broader picture, there could be cross subsystem critical data being measured based on a single label. Please think about the broader picture and re-write the patch descirption more generically. Makes sense. Will make the patch description more generic. Add a new IMA policy condition - "data_source:=" to the IMA func What is with "add"? You're "adding support for" or "defining" a new policy condition. Remove the single hyphen, as explained in 3/8. Please replace "data_source" with something more generic (e.g. label). Sounds good. Would you prefer "label" or something else like "data_label"? In the policy file the "label" looks logical and more generic than "data_label". measure func=CRITICAL_DATA label=selinux For the time being, I will stick with "label", please let me know if you prefer something else. Thanks, Tushar thanks, Mimi CRITICAL_DATA to allow measurement of various kernel subsystems. This policy condition would enable the system administrators to restrict the measurement to the labels listed in "data_source:=". Limit the measurement to the labels that are specified in the IMA policy - CRITICAL_DATA+"data_source:=". 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
Re: [PATCH v9 7/8] IMA: define a builtin critical data measurement policy
On 2020-12-24 6:41 a.m., Mimi Zohar wrote: On Sat, 2020-12-12 at 10:02 -0800, Tushar Sugandhi wrote: From: Lakshmi Ramasubramanian 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". This sentence isn't really necessary. Will remove. Update the documentation on kernel parameters to document the new critical data builtin policy. Signed-off-by: Lakshmi Ramasubramanian Reviewed-by: Tyler Hicks Otherwise, Reviewed-by: Mimi Zohar Thanks again for the "Reviewed-by" tag. Thanks, Tushar thanks, Mimi
Re: [PATCH v9 2/8] IMA: add support to measure buffer data hash
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);
Please abbreviate the boolean name to "hash". The test would then be
"if (hash == true)" or "if (hash)".
Will do.
- * 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
^@hash: measure buffer data hash
Agreed. Will fix.
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,13 +862,27 @@ void process_buffer_measurement(struct inode
*inode, const void *buf, int size,
goto out;
}
+ if (measure_buf_hash) {
^ if (hash) {
Yes.
+ 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";
Hi Mimi,
There already exist a local struct variable named "hash" in p_b_m().
I was thinking of using "buf_hash", but that one is taken too.
Maybe I should use "buf_hash" for the input bool, and rename the
existing "buf_hash" local variable to "digest_hash"?
Does it sound ok?
Thanks,
Tushar
Re: [PATCH v6 0/8] IMA: support for measuring kernel integrity critical data
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
Re: [PATCH v2 2/3] IMA: add policy to support measuring critical data from kernel components
On 2020-08-24 3:46 p.m., Mimi Zohar wrote: On Fri, 2020-08-21 at 11:21 -0700, Tushar Sugandhi wrote: There would be several candidate kernel components suitable for IMA measurement. Not all of them would have support for IMA measurement. Also, system administrators may not want to measure data for all of them, even when they support IMA measurement. An IMA policy specific to various kernel components is needed to measure their respective critical data. Add a new IMA policy CRITICAL_DATA+data_sources to support measuring various critical kernel components. This policy would enable the system administrators to limit the measurement to the components, if the components support IMA measurement. Signed-off-by: Tushar Sugandhi --- Documentation/ABI/testing/ima_policy | 6 ++- security/integrity/ima/ima.h | 1 + security/integrity/ima/ima_api.c | 2 +- security/integrity/ima/ima_policy.c | 62 +--- 4 files changed, 63 insertions(+), 8 deletions(-) diff --git a/Documentation/ABI/testing/ima_policy b/Documentation/ABI/testing/ima_policy index cd572912c593..a0dd0f108555 100644 --- a/Documentation/ABI/testing/ima_policy +++ b/Documentation/ABI/testing/ima_policy @@ -29,7 +29,7 @@ Description: base: 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 @@ -125,3 +125,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|apparmor|dm-crypt This example uses "data_sources" without first defining it in the "option:" section. Defining two new options is an indication that this Thanks. I will define "data_sources" first in "option:" section. patch should be split up. One which defines the "CRITICAL_DATA" and another one which defines the new key value pair. The term I intentionally kept the "CRITICAL_DATA" and "data_sources" in the same patch. CRITICAL_DATA is different than KEY_CHECK because in case of KEY_CHECK, "keyrings=" is optional. If "keyrings=" is not specified, then we measure all keyrings. Where for CRITICAL_DATA, "data_sources=" is mandatory. Because the data sources would be diverse and orthogonal to each other, (unlike "keyrings=") - not specifying "data_sources=" shouldn't result in IMA blindly measuring all data sources. Since CRITICAL_DATA, and "data_sources=" go hand in hand, I wanted them to be part of the same patch. "data_sources" is pretty generic. Perhaps constrain it a bit by re- naming it "critical_data=". Or was such using a generic name intentional? We intentionally kept the name generic because the data to be measured could be coming from any kernel component with any granularity (from a single bool to megabytes of data). The kernel component is also loosely defined here. It could be an LSM (like SELinux), or a broader base layer (like device-mapper), or a specific module (like dm-crypt), or it could be different parts of a single module. Also, we didn't want to name "data_sources" as "critical_data" to avoid confusion with func "CRITICAL_DATA". Normally "CRITICAL_DATA" would be defined with the critical data hook, but that seems to be defined in patch 3/3 "IMA: define IMA hook to measure critical data from kernel components". I can make the "CRITICAL_DATA" and the hook as part of the same patch. That would mean combining patch 2 and 3 into a single one. Does it sound ok? diff --git a/security/integrity/ima/ima.h b/security/integrity/ima/ima.h index 8875085db689..0f4209a92bfb 100644 --- a/security/integrity/ima/ima.h +++ b/security/integrity/ima/ima.h @@ -200,6 +200,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.
Re: [PATCH v2 2/3] IMA: add policy to support measuring critical data from kernel components
On 2020-08-25 1:43 p.m., Mimi Zohar wrote: On Tue, 2020-08-25 at 10:32 -0700, Tushar Sugandhi wrote: On 2020-08-24 3:46 p.m., Mimi Zohar wrote: On Fri, 2020-08-21 at 11:21 -0700, Tushar Sugandhi wrote: There would be several candidate kernel components suitable for IMA measurement. Not all of them would have support for IMA measurement. Also, system administrators may not want to measure data for all of them, even when they support IMA measurement. An IMA policy specific to various kernel components is needed to measure their respective critical data. Add a new IMA policy CRITICAL_DATA+data_sources to support measuring various critical kernel components. This policy would enable the system administrators to limit the measurement to the components, if the components support IMA measurement. Signed-off-by: Tushar Sugandhi --- Documentation/ABI/testing/ima_policy | 6 ++- security/integrity/ima/ima.h | 1 + security/integrity/ima/ima_api.c | 2 +- security/integrity/ima/ima_policy.c | 62 +--- 4 files changed, 63 insertions(+), 8 deletions(-) diff --git a/Documentation/ABI/testing/ima_policy b/Documentation/ABI/testing/ima_policy index cd572912c593..a0dd0f108555 100644 --- a/Documentation/ABI/testing/ima_policy +++ b/Documentation/ABI/testing/ima_policy @@ -29,7 +29,7 @@ Description: base: 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 @@ -125,3 +125,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|apparmor|dm-crypt This example uses "data_sources" without first defining it in the "option:" section. Defining two new options is an indication that this Thanks. I will define "data_sources" first in "option:" section. patch should be split up. One which defines the "CRITICAL_DATA" and another one which defines the new key value pair. The term I intentionally kept the "CRITICAL_DATA" and "data_sources" in the same patch. CRITICAL_DATA is different than KEY_CHECK because in case of KEY_CHECK, "keyrings=" is optional. If "keyrings=" is not specified, then we measure all keyrings. Where for CRITICAL_DATA, "data_sources=" is mandatory. Because the data sources would be diverse and orthogonal to each other, (unlike "keyrings=") - not specifying "data_sources=" shouldn't result in IMA blindly measuring all data sources. Good point. Since CRITICAL_DATA, and "data_sources=" go hand in hand, I wanted them to be part of the same patch. Separating them will help clarify the patch description. There's no harm in defining the critical data source first. I will put func=CRITICAL_DATA into one patch, and "data_sources=" into the next patch. Coding wise, the reverse order of patches (where "data_sources=" goes in the first patch, before func=CRITICAL_DATA) doesn't make sense. Because ima_match_rules() etc. have switch cases built around func=CRITICAL_DATA etc. "data_sources" is pretty generic. Perhaps constrain it a bit by re- naming it "critical_data=". Or was such using a generic name intentional? We intentionally kept the name generic because the data to be measured could be coming from any kernel component with any granularity (from a single bool to megabytes of data). The kernel component is also loosely defined here. It could be an LSM (like SELinux), or a broader base layer (like device-mapper), or a specific module (like dm-crypt), or it could be different parts of a single module. Also, we didn't want to name "data_sources" as "critical_data" to avoid confusion with func "CRITICAL_DATA". The point is that you're measuring critical data, not just any data from any source. Whatever term is used, it needs to be added to the Documentation/ABI/testing/ima_policy. I think something that is self describing will help. See what makes the most sense. Fair enough. Does "critical_kernel_data_sources=" sound ok? Normally "CRITICAL_DATA" would be defined with the critical data hook, but that seems to be defined in patch 3/3 "IMA: define IMA hook t
[PATCH v3 0/6] IMA: Infrastructure for measurement of critical kernel data
There are several kernel components that contain critical data which if
accidentally or maliciously altered, can compromise the security of the
kernel. Example of such components would include LSMs like SELinux, or
AppArmor; or device-mapper targets like dm-crypt, dm-verity etc.
Many of these components do not use the capabilities provided by kernel
integrity subsystem (IMA), and thus they don't use the benefits of
extended TPM PCR quotes and ultimately the benefits of remote attestation.
This series bridges this gap, so that potential kernel components that
contain data critical to the security of the kernel could take advantage
of IMA's measuring and quoting abilities - thus ultimately enabling
remote attestation for their specific data.
System administrators may want to pick and choose which kernel
components they would want to enable for measurements, quoting, and
remote attestation. To enable that, a new IMA policy is introduced.
And lastly, the functionality is exposed through a function
ima_measure_critical_data(). The functionality is generic enough to
measure the data of any kernel component at run-time. To ensure that only
data from supported sources are measured, the kernel component needs to
be added to a compile-time list of supported sources (an "allowed list
of components"). IMA validates the source passed to
ima_measure_critical_data() against this allowed list at run-time.
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 d012a7190fc1 ("Linux 5.9-rc2")
This series also has a dependency on the following patch series:
https://patchwork.kernel.org/patch/11709527/
Change Log v3:
Incorporated feedback from Mimi on v2.
- Renamed the policy "data_sources" to
"critical_kernel_data_sources".
- Added "critical_kernel_data_sources" description in
Documentation/ima-policy.
- Split CRITICAL_DATA + critical_kernel_data_sources into two separate
patches.
- Merged hook ima_measure_critical_data() + CRITICAL_DATA into a single
patch.
- Added functionality to validate data sources before measurement.
Change Log v2:
- Reverted the unnecessary indentations in existing #define.
- Updated the description to replace the word 'enlightened' with
'supported'.
- Reverted the unnecessary rename of attribute size to buf_len.
- Introduced a boolean parameter measure_buf_hash as per community
feedback to support measuring hash of the buffer, instead of the
buffer itself.
Tushar Sugandhi (6):
IMA: generalize keyring specific measurement constructs
IMA: change process_buffer_measurement return type from void to int
IMA: update process_buffer_measurement to measure buffer hash
IMA: add policy to measure critical data from kernel components
IMA: add hook to measure critical data from kernel components
IMA: validate supported kernel data sources before measurement
Documentation/ABI/testing/ima_policy | 11 +-
include/linux/ima.h | 11 ++
security/integrity/ima/ima.h | 41 +++-
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| 72 +++--
security/integrity/ima/ima_policy.c | 101 +++
security/integrity/ima/ima_queue_keys.c | 3 +-
9 files changed, 205 insertions(+), 46 deletions(-)
--
2.17.1
[PATCH v3 1/6] IMA: generalize keyring specific measurement constructs
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 without code duplication.
Refactor the keyring specific measurement constructs to be generic and
reusable in other measurement scenarios.
Signed-off-by: Tushar Sugandhi
---
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 | 42 -
4 files changed, 33 insertions(+), 27 deletions(-)
diff --git a/security/integrity/ima/ima.h b/security/integrity/ima/ima.h
index 38043074ce5e..8875085db689 100644
--- a/security/integrity/ima/ima.h
+++ b/security/integrity/ima/ima.h
@@ -255,7 +255,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,
@@ -267,7 +267,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,
@@ -283,7 +283,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 8a91711ca79b..c870fd6d2f83 100644
--- a/security/integrity/ima/ima_main.c
+++ b/security/integrity/ima/ima_main.c
@@ -732,13 +732,13 @@ int ima_load_data(enum kernel_load_data_id id)
* @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";
@@ -770,7 +770,7 @@ void process_buffer_measurement(struct inode *inode, const
[PATCH v3 5/6] IMA: add hook to measure critical data from kernel components
Currently, IMA does not provide a generic function for kernel components
to measure their data. A generic function provided by IMA would
enable various parts of the kernel with easier and faster on-boarding to
use IMA infrastructure, would avoid code duplication, and consistent
usage of IMA policy "critical_kernel_data_sources" across the kernel.
Add a new IMA func CRITICAL_DATA and a corresponding IMA hook
ima_measure_critical_data() to support measuring various critical kernel
components. Limit the measurement to the components that are specified
in the IMA policy - CRITICAL_DATA+critical_kernel_data_sources.
Signed-off-by: Tushar Sugandhi
---
Documentation/ABI/testing/ima_policy | 8 ++-
include/linux/ima.h | 11 +
security/integrity/ima/ima.h | 1 +
security/integrity/ima/ima_api.c | 2 +-
security/integrity/ima/ima_main.c| 24
security/integrity/ima/ima_policy.c | 34
6 files changed, 73 insertions(+), 7 deletions(-)
diff --git a/Documentation/ABI/testing/ima_policy
b/Documentation/ABI/testing/ima_policy
index 7ccdc1964e29..36d9cee9704d 100644
--- a/Documentation/ABI/testing/ima_policy
+++ b/Documentation/ABI/testing/ima_policy
@@ -29,7 +29,7 @@ Description:
base: 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
@@ -51,6 +51,8 @@ Description:
critical_kernel_data_sources:= list of kernel
components (eg, selinux|apparmor|dm-crypt) that
contain data critical to the security of the kernel.
+ Only valid when action is "measure" and func is
+ CRITICAL_DATA.
default policy:
# PROC_SUPER_MAGIC
@@ -128,3 +130,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
critical_kernel_data_sources=selinux|apparmor|dm-crypt
diff --git a/include/linux/ima.h b/include/linux/ima.h
index d15100de6cdd..136fc02580db 100644
--- a/include/linux/ima.h
+++ b/include/linux/ima.h
@@ -26,6 +26,10 @@ 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 int ima_measure_critical_data(const char *event_name,
+const char *event_data_source,
+const void *buf, int buf_len,
+bool measure_buf_hash);
#ifdef CONFIG_IMA_KEXEC
extern void ima_add_kexec_buffer(struct kimage *image);
@@ -104,6 +108,13 @@ 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 int ima_measure_critical_data(const char *event_name,
+ const char *event_data_source,
+ const void *buf, int buf_len,
+ bool measure_buf_hash)
+{
+ return -EOPNOTSUPP;
+}
#endif /* CONFIG_IMA */
#ifndef CONFIG_IMA_KEXEC
diff --git a/security/integrity/ima/ima.h b/security/integrity/ima/ima.h
index ba332de8ed0b..00b84052c8f1 100644
--- a/security/integrity/ima/ima.h
+++ b/security/integrity/ima/ima.h
@@ -200,6 +200,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
[PATCH v3 4/6] IMA: add policy to measure critical data from kernel components
There would be several candidate kernel components suitable for IMA
measurement. Not all of them would have support for IMA measurement.
Also, system administrators may not want to measure data for all of
them, even when they support IMA measurement. An IMA policy specific
to various kernel components is needed to measure their respective
critical data.
Add a new IMA policy "critical_kernel_data_sources" to support measuring
various critical kernel components. This policy would enable the
system administrators to limit the measurement to the components,
if the components support IMA measurement.
Signed-off-by: Tushar Sugandhi
---
Documentation/ABI/testing/ima_policy | 3 +++
security/integrity/ima/ima_policy.c | 29 +++-
2 files changed, 31 insertions(+), 1 deletion(-)
diff --git a/Documentation/ABI/testing/ima_policy
b/Documentation/ABI/testing/ima_policy
index cd572912c593..7ccdc1964e29 100644
--- a/Documentation/ABI/testing/ima_policy
+++ b/Documentation/ABI/testing/ima_policy
@@ -48,6 +48,9 @@ Description:
template:= name of a defined IMA template type
(eg, ima-ng). Only valid when action is "measure".
pcr:= decimal value
+ critical_kernel_data_sources:= list of kernel
+ components (eg, selinux|apparmor|dm-crypt) that
+ contain data critical to the security of the kernel.
default policy:
# PROC_SUPER_MAGIC
diff --git a/security/integrity/ima/ima_policy.c
b/security/integrity/ima/ima_policy.c
index 8866e84d0062..c8a044705347 100644
--- a/security/integrity/ima/ima_policy.c
+++ b/security/integrity/ima/ima_policy.c
@@ -33,6 +33,7 @@
#define IMA_PCR0x0100
#define IMA_FSNAME 0x0200
#define IMA_KEYRINGS 0x0400
+#define IMA_DATA_SOURCES 0x0800
#define UNKNOWN0
#define MEASURE0x0001 /* same as IMA_MEASURE */
@@ -84,6 +85,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;
};
@@ -911,7 +913,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 = {
@@ -948,6 +950,7 @@ static const match_table_t policy_tokens = {
{Opt_pcr, "pcr=%s"},
{Opt_template, "template=%s"},
{Opt_keyrings, "keyrings=%s"},
+ {Opt_data_sources, "critical_kernel_data_sources=%s"},
{Opt_err, NULL}
};
@@ -1312,6 +1315,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, "critical_kernel_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);
@@ -1692,6 +1713,12 @@ int ima_policy_show(struct seq_file *m, void *v)
seq_puts(m, " ");
}
+ if (entry->flags & IMA_DATA_SOURCES) {
+ seq_puts(m, "critical_kernel_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
[PATCH v3 6/6] IMA: validate supported kernel data sources before measurement
Currently, IMA does not restrict random data sources from measuring their
data using ima_measure_critical_data(). Any kernel data source can call
the function, and it's data will get measured as long as the input
event_data_source is part of the IMA policy -
CRITICAL_DATA+critical_kernel_data_sources. This may result in IMA log
getting bloated by random data sources. Supporting random data sources
at run-time may also impact the reliability of the system.
To ensure that only data from supported sources are measured, the kernel
component needs to be added to a compile-time list of supported sources
(an "allowed list of components") in ima.h. IMA then validates the input
parameter - event_data_source passed to ima_measure_critical_data()
against this allowed list at run-time.
Provide an infrastructure for kernel data sources to be added to
the supported data sources list at compile-time. Update
ima_measure_critical_data() to validate, at run-time, that the data
source is supported before measuring the data.
Signed-off-by: Tushar Sugandhi
---
security/integrity/ima/ima.h | 29 +
security/integrity/ima/ima_main.c | 3 +++
2 files changed, 32 insertions(+)
diff --git a/security/integrity/ima/ima.h b/security/integrity/ima/ima.h
index 00b84052c8f1..ecb0a1e7378f 100644
--- a/security/integrity/ima/ima.h
+++ b/security/integrity/ima/ima.h
@@ -228,6 +228,35 @@ extern const char *const func_tokens[];
struct modsig;
+#define __ima_supported_kernel_data_sources(source)\
+ source(MIN_SOURCE, min_source) \
+ source(MAX_SOURCE, max_source)
+
+#define __ima_enum_stringify(ENUM, str) (#str),
+
+enum ima_supported_kernel_data_sources {
+ __ima_supported_kernel_data_sources(__ima_hook_enumify)
+};
+
+static const char * const ima_supported_kernel_data_sources_str[] = {
+ __ima_supported_kernel_data_sources(__ima_enum_stringify)
+};
+
+static inline bool ima_kernel_data_source_is_supported(const char *source)
+{
+ int i;
+
+ if (!source)
+ return false;
+
+ for (i = MIN_SOURCE + 1; i < MAX_SOURCE; i++) {
+ if (!strcmp(ima_supported_kernel_data_sources_str[i], source))
+ return true;
+ }
+
+ return false;
+}
+
#ifdef CONFIG_IMA_QUEUE_EARLY_BOOT_KEYS
/*
* To track keys that need to be measured.
diff --git a/security/integrity/ima/ima_main.c
b/security/integrity/ima/ima_main.c
index a889bf40cb7e..41be4d1d839e 100644
--- a/security/integrity/ima/ima_main.c
+++ b/security/integrity/ima/ima_main.c
@@ -888,6 +888,9 @@ int ima_measure_critical_data(const char *event_name,
if (!event_name || !event_data_source || !buf || !buf_len)
return -EINVAL;
+ if (!ima_kernel_data_source_is_supported(event_data_source))
+ return -EPERM;
+
return process_buffer_measurement(NULL, buf, buf_len, event_name,
CRITICAL_DATA, 0, event_data_source,
measure_buf_hash);
--
2.17.1
[PATCH v3 3/6] IMA: update process_buffer_measurement to measure buffer hash
process_buffer_measurement() currently only measures the input buffer.
When the buffer being measured is too large, it may result in bloated
IMA logs.
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
---
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, 32 insertions(+), 7 deletions(-)
diff --git a/security/integrity/ima/ima.h b/security/integrity/ima/ima.h
index 83ed57147e68..ba332de8ed0b 100644
--- a/security/integrity/ima/ima.h
+++ b/security/integrity/ima/ima.h
@@ -267,7 +267,8 @@ void ima_store_measurement(struct integrity_iint_cache
*iint, struct file *file,
struct ima_template_desc *template_desc);
int 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 372d16382960..20adffe5bf58 100644
--- a/security/integrity/ima/ima_appraise.c
+++ b/security/integrity/ima/ima_appraise.c
@@ -336,7 +336,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 0979a62a9257..52cbbc1f7ea2 100644
--- a/security/integrity/ima/ima_main.c
+++ b/security/integrity/ima/ima_main.c
@@ -733,17 +733,21 @@ int ima_load_data(enum kernel_load_data_id id)
* @func: IMA hook
* @pcr: pcr to extend the measurement
* @func_data: private data specific to @func, can be NULL.
+ * @measure_buf_hash: if set to true - will measure hash of the buf,
+ *instead of buf
*
* Based on policy, the buffer is measured into the ima log.
*/
int 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";
struct ima_template_entry *entry = NULL;
struct integrity_iint_cache iint = {};
+ struct integrity_iint_cache digest_iint = {};
struct ima_event_data event_data = {.iint = &iint,
.filename = eventname,
.buf = buf,
@@ -752,7 +756,7 @@ int process_buffer_measurement(struct inode *inode, const
void *buf, int size,
struct {
struct ima_digest_data hdr;
char digest[IMA_MAX_DIGEST_SIZE];
- } hash = {};
+ } hash = {}, digest_hash = {};
int violation = 0;
int action = 0;
u32 secid;
@@ -801,6 +805,24 @@ int process_buffer_measurement(struct inode *inode, const
void *buf, int size,
goto out;
}
+ if (measure_buf_hash) {
+ digest_iint.ima_hash = &digest_hash.hdr;
+ digest_iint.ima_hash->algo = ima_hash_algo;
+ digest_iint.ima_hash->length = hash_digest_size[ima_hash_algo];
+
+ ret = ima_calc_buffer_hash(hash.hdr.digest,
+
[PATCH v3 2/6] IMA: change process_buffer_measurement return type from void to int
process_buffer_measurement() does not return the result of the operation.
Therefore, the consumers of this function cannot act on it, if needed.
Update return type of process_buffer_measurement() from void to int.
Signed-off-by: Tushar Sugandhi
---
security/integrity/ima/ima.h | 6 +++---
security/integrity/ima/ima_main.c | 14 +++---
2 files changed, 10 insertions(+), 10 deletions(-)
diff --git a/security/integrity/ima/ima.h b/security/integrity/ima/ima.h
index 8875085db689..83ed57147e68 100644
--- a/security/integrity/ima/ima.h
+++ b/security/integrity/ima/ima.h
@@ -265,9 +265,9 @@ void ima_store_measurement(struct integrity_iint_cache
*iint, struct file *file,
struct evm_ima_xattr_data *xattr_value,
int xattr_len, const struct modsig *modsig, int pcr,
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 process_buffer_measurement(struct inode *inode, const void *buf, int size,
+ const char *eventname, enum ima_hooks func,
+ 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,
diff --git a/security/integrity/ima/ima_main.c
b/security/integrity/ima/ima_main.c
index c870fd6d2f83..0979a62a9257 100644
--- a/security/integrity/ima/ima_main.c
+++ b/security/integrity/ima/ima_main.c
@@ -736,9 +736,9 @@ int ima_load_data(enum kernel_load_data_id id)
*
* 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 *func_data)
+int 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 ret = 0;
const char *audit_cause = "ENOMEM";
@@ -758,7 +758,7 @@ void process_buffer_measurement(struct inode *inode, const
void *buf, int size,
u32 secid;
if (!ima_policy_flag)
- return;
+ return 0;
/*
* Both LSM hooks and auxilary based buffer measurements are
@@ -772,7 +772,7 @@ void process_buffer_measurement(struct inode *inode, const
void *buf, int size,
action = ima_get_action(inode, current_cred(), secid, 0, func,
&pcr, &template, func_data);
if (!(action & IMA_MEASURE))
- return;
+ return 0;
}
if (!pcr)
@@ -787,7 +787,7 @@ void process_buffer_measurement(struct inode *inode, const
void *buf, int size,
pr_err("template %s init failed, result: %d\n",
(strlen(template->name) ?
template->name : template->fmt), ret);
- return;
+ return ret;
}
}
@@ -819,7 +819,7 @@ void process_buffer_measurement(struct inode *inode, const
void *buf, int size,
func_measure_str(func),
audit_cause, ret, 0, ret);
- return;
+ return ret;
}
/**
--
2.17.1
[PATCH v3 2/2] dm-crypt: collect data and submit to DM to measure
Currently, dm-crypt does not take advantage of IMA measuring
capabilities, and ultimately the benefits of remote attestation.
Measure various dm-crypt constructs by calling various device-mapper
functions - dm_ima_*() that use IMA measuring capabilities. Implement
ima_measure_dm_crypt_data() to measure various dm-crypt constructs.
Ensure that ima_measure_dm_crypt_data() is non intrusive, i.e. failures
in this function and the call-stack below should not affect the core
functionality of dm-crypt.
Register dm-crypt as supported data source for IMA measurement in ima.h.
A demonstrative usage of above functionality on a system:
If the IMA policy contains the following rule:
measure func=CRITICAL_DATA critical_kernel_data_sources=dm-crypt
template=ima-buf
and, the following commands are used to setup a crypt target:
#key="faf453b4ee938cff2f0d2c869a0b743f59125c0a37f5bcd8f1dbbd911a78abaa"
#arg="'0 1953125 crypt aes-xts-plain64 "
#arg="$arg $key 0 "
#arg="$arg /dev/loop0 0 1 allow_discards'"
#tgt_name="test-crypt"
#cmd="dmsetup create $tgt_name --table $arg"
#eval $cmd
then, the IMA log at
/sys/kernel/security/integrity/ima/ascii_runtime_measurements should
contain the dm-crypt measurements. And, the following IMA log entry
should be added in the IMA log,
ima-buf sha1:039d8ff71918608d585adca3e5aab2e3f41f84d6
1598637500:520585536:dm-crypt:add_target
74695f6e756d5f646973636172645f62696f733d313b7065725f62696f5f646
174615f73697a653d3834383b646d7265715f73746172743d3136383b74666d
735f636f756e743d313b6f6e5f6469736b5f7461675f73697a653d303b696e7
46567726974795f69765f73697a653d303b696e746567726974795f7461675f
73697a653d303b69765f73697a653d31363b69765f6f7365743d303b736
563746f725f73686966743d303b736563746f725f73697a653d3531323b666c
6167733d323b6369706865725f666c6167733d303b73746172743d303b6b657
95f6d61635f73697a653d303b6b65795f65787472615f73697a653d303b6b65
795f70617274733d313b6b65795f73697a653d33323b6369706865725f73747
2696e673d6165732d7874732d706c61696e36343b6465766963655f6e616d65
3d3235333a303b
where, the ascii representation of the above data is:
ti_num_discard_bios=1;per_bio_data_size=848;dmreq_start=168;
tfms_count=1;on_disk_tag_size=0;integrity_iv_size=0;
integrity_tag_size=0;iv_size=16;iv_offset=0;sector_shift=0;
sector_size=512;flags=2;cipher_flags=0;start=0;key_mac_size=0;
key_extra_size=0;key_parts=1;key_size=32;
cipher_string=aes-xts-plain64;device_name=253:0;
Some of the above values can be verified using:
#dmsetup table --showkeys
where, the output of the command should be similar to:
test-crypt: 0 1953125 crypt aes-xts-plain64
faf453b4ee938cff2f0d2c869a0b743f59125c0a37f5bcd8f1dbbd911a78abaa
0 7:0 0 1 allow_discards
Signed-off-by: Tushar Sugandhi
---
drivers/md/dm-crypt.c | 171 +
security/integrity/ima/Kconfig | 3 +-
security/integrity/ima/ima.h | 1 +
3 files changed, 173 insertions(+), 2 deletions(-)
diff --git a/drivers/md/dm-crypt.c b/drivers/md/dm-crypt.c
index 148960721254..47fb2ce15211 100644
--- a/drivers/md/dm-crypt.c
+++ b/drivers/md/dm-crypt.c
@@ -2529,6 +2529,8 @@ static void crypt_dtr(struct dm_target *ti)
ti->private = NULL;
+ dm_ima_exit_measurements(ti->type);
+
if (!cc)
return;
@@ -2991,6 +2993,167 @@ static int crypt_report_zones(struct dm_target *ti,
#endif
+#ifdef CONFIG_IMA
+/*
+ * append integer values to dm-crypt specific data
+ * to be measured through IMA
+ */
+static int ima_append_num_values(struct dm_target *ti,
+const char *key,
+long long num_val)
+{
+ char *num_str = NULL;
+ int length = 0;
+ int r = 0;
+
+ if (!ti || !key) {
+ r = -EINVAL;
+ goto error;
+ }
+
+ length = snprintf(NULL, 0, "%lld", num_val);
+ num_str = kzalloc(length + 1, GFP_KERNEL);
+ if (!num_str) {
+ r = -ENOMEM;
+ goto error;
+ }
+ snprintf(num_str, length + 1, "%lld", num_val);
+ dm_ima_append_measurement_list(ti->type,
+ key,
+ (const void *)num_str,
+ length);
+ kzfree(num_str);
+ return r;
+error:
+ DMERR("appending num values to IMA measurement list failed %d", r);
+ return r;
+}
+/*
+ * Measure dm-crypt specific data through IMA.
+ * It appends all the needed data to the list as a key-val pair using
+ * dm_ima_append_measurement_list() and internal ima_append_num_values(),
+ * and finally measures the list using dm_ima_finalize_and_measure().
+ */
+static void ima_measure_dm_crypt_data(struct dm_target *ti, const char *desc)
+{
+ int r = 0;
+ struct crypt_config *cc = NULL;
+ const char *devname
[PATCH v3 1/2] dm-devel: collect target data and submit to IMA to measure
For the device-mapper targets to take advantage of IMA's measuring and
quoting abilities, and for enabling remote attestation for device-mapper
targets, device-mapper needs to provide the functionality to
consistently measure target data using ima_measure_critical_data()
function provided by IMA. A generic set of functions at device-mapper
layer would enable the measurement structure to be uniform across
targets, and avoid code duplication. It will also make on-boarding
easier and faster for targets that want to use IMA infrastructure for
measurements, quoting, and remote attestation. The uniform measurement
structure across targets would also help the remote attestation services
to consistently process, across targets, the measurement to be attested.
Implement a set of functions at device-mapper layer to manage the data
coming from various device-mapper targets to be measured by IMA.
Provide the functionality for various tasks - initialize the necessary
data structures, add the data to the list of key-value pairs to be be
measured, reset the list if needed (e.g. in error/retry cases), and
finally pass it on to device-mapper layer, to be measured by IMA.
Ensure the functionality is generic and implemented at device-mapper
layer, so that any device-mapper target can use it to measure its data
through IMA.
Also make sure the functionality is non-intrusive/best effort for the
targets using it. The errors in managing the list to be measured, and
the actual errors in the measurement should not disrupt the core
functionality of the targets.
Protect the list of key value pairs to be measured for a given target,
by putting it under critical sections - so that multi-threaded targets
can safely use the list to append the data from different threads, for
measurements and quoting.
Compute the last measurement's hash and store it internally, so that
unnecessary duplicate data is not sent to IMA for measurement.
Divide the functionality into 5 main functions:
(1) dm_ima_init_measurements(): Use it to initialize device-mapper
target's IMA measurement list. It should abstract the necessary data
initialization from the device-mapper target apps.
(2) dm_ima_append_measurement_list(): Use it to append the key-value
pair to the existing list of key-value pairs to measure.
(3) dm_ima_finalize_and_measure(): Use it to measure the key-value pair
list for a given target, and finally release the resources held by the
list for that specific target.
Note that the data given by the target for a given device would be
sent to IMA subsystem for measurement only if it has changed since the
last time it was measured.
(4) dm_ima_reset_measurement_list(): Use it to reset device-mapper
target's ima measurement list, by releasing the resources held by the
list. Use it if the measurements list need to be reset after
dm_ima_init_measurements() and before calling
dm_ima_finalize_and_measure().
This can be needed in scenarios like recovering from error paths and
retrying measurements and quoting again.
(5) dm_ima_exit_measurements(): Use it during the destruction of the
target - to release the resources held for measurement. This is useful
to protect the kernel from possible resource leaks when the target adds
data for measurements using dm_ima_append_measurement_list(), but gets
destroyed before calling dm_ima_finalize_and_measure().
Signed-off-by: Tushar Sugandhi
---
drivers/md/Makefile | 1 +
drivers/md/dm-ima.c | 298 ++
include/linux/device-mapper.h | 60 +++
3 files changed, 359 insertions(+)
create mode 100644 drivers/md/dm-ima.c
diff --git a/drivers/md/Makefile b/drivers/md/Makefile
index 6d3e234dc46a..0dc50181aaf2 100644
--- a/drivers/md/Makefile
+++ b/drivers/md/Makefile
@@ -77,6 +77,7 @@ obj-$(CONFIG_DM_LOG_WRITES) += dm-log-writes.o
obj-$(CONFIG_DM_INTEGRITY) += dm-integrity.o
obj-$(CONFIG_DM_ZONED) += dm-zoned.o
obj-$(CONFIG_DM_WRITECACHE)+= dm-writecache.o
+obj-$(CONFIG_IMA) += dm-ima.o
ifeq ($(CONFIG_DM_INIT),y)
dm-mod-objs+= dm-init.o
diff --git a/drivers/md/dm-ima.c b/drivers/md/dm-ima.c
new file mode 100644
index ..2651e5c88395
--- /dev/null
+++ b/drivers/md/dm-ima.c
@@ -0,0 +1,298 @@
+// SPDX-License-Identifier: GPL-2.0+
+/*
+ * Copyright (C) 2020 Microsoft Corporation
+ *
+ * Author: Tushar Sugandhi
+ *
+ * File: dm-ima.c
+ * Enables IMA measurements for DM targets
+ */
+
+#include "dm-core.h"
+
+#include
+#include
+#include
+#include
+#include
+
+#define DM_MSG_PREFIX "ima"
+
+static int dm_compute_buffer_hash(void *buf,
+ size_t buf_len,
+ void **buf_hash,
+ int *buf_hash_len)
+{
+ struct crypto_shash *tfm;
+ struct shash_desc *desc = NULL;
+ void *digest = NULL;
+ int desc_size;
+ int digest_
[PATCH v3 0/2] dm-devel:dm-crypt: infrastructure for measurement of DM target data using IMA
There are several device-mapper targets which contribute to verify
the integrity of the mapped devices e.g. dm-integrity, dm-verity,
dm-crypt etc.
But they do not use the capabilities provided by kernel integrity
subsystem (IMA). For instance, the IMA capability that measures several
in-memory constructs and files to detect if they have been accidentally
or maliciously altered. IMA also has the capability to include these
measurements in the IMA measurement list and use them to extend a TPM
PCR so that they can be quoted. These TPM PCR extend operations ensure
that the tampering with the order of constructs being measured, and
tampering with the measured constructs themselves - doesn't go
undetected. In general, this capability is used for remote attestation
of in-memory constructs and files of interest. As of today,device-mapper
targets don't use the benefits of extended TPM PCR quotes and ultimately
the benefits of remote attestation.
This series bridges this gap, so that all device-mapper targets
could take advantage of IMA's measuring and quoting abilities - thus
ultimately enabling remote attestation for device-mapper targets.
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 d012a7190fc1 ("Linux 5.9-rc2")
This series also has a dependency on the following patch series and
should be applied in the following order:
1. https://patchwork.kernel.org/patch/11709527/
2. https://patchwork.kernel.org/patch/11742047/
3. https://patchwork.kernel.org/patch/11743265/
Change Log v3:
- add dm-crypt as a supported data source to measure in ima.h.
- Taken dependency on the updated base series v3 (2. above)
- Taken dependency on the updated early boot measurement series v2
(3. above).
Change Log v2:
- Removed the references to "local" measurement from the description -
as this series only support remote attestation, and not local
integrity enforcement.
- Taken dependency on the updated base series (2. above), which
introduced a boolean parameter measure_buf_hash as per community
feedback to support measuring hash of the buffer, instead of the
buffer itself.
- Taken dependency on the updated early boot measurement series
(3. above).
Tushar Sugandhi (2):
dm-devel: collect target data and submit to IMA to measure
dm-crypt: collect data and submit to DM to measure
drivers/md/Makefile| 1 +
drivers/md/dm-crypt.c | 171 +++
drivers/md/dm-ima.c| 298 +
include/linux/device-mapper.h | 60 +++
security/integrity/ima/Kconfig | 3 +-
security/integrity/ima/ima.h | 1 +
6 files changed, 532 insertions(+), 2 deletions(-)
create mode 100644 drivers/md/dm-ima.c
--
2.17.1
Re: [PATCH 2/3] IMA: add policy to support measuring critical data from kernel components
On 2020-08-17 1:43 p.m., Mimi Zohar wrote: On Wed, 2020-08-12 at 12:31 -0700, Tushar Sugandhi wrote: There would be several candidate kernel components suitable for IMA measurement. Not all of them would be enlightened for IMA measurement. Also, system administrators may not want to measure data for all of them, even when they are enlightened for IMA measurements. An IMA policy specific to various kernel components is needed to measure their respective critical data. Add a new IMA policy CRITICAL_DATA+data_sources to support measuring various critical kernel components. This policy would enable the system administrators to limit the measurement to the components, if the components are enlightened for IMA measurement. "enlightened", really? Please find a different term, maybe something like "supported". Thanks for the feedback Mimi. Will do. Before posting a patch set, please look at the patches line by line, like anyone reviewing the code needs to do. Please minimize code change. Unnecessary formatting changes are unacceptible. For example, like the "#define", below, or in 3/3 the Thanks for the feedback Mimi. We extensively reviewed the patches internally before submitting for upstream review. We believed adding an extra tab was necessary so that all the previous values were aligned with the new one - #define IMA_DATA_SOURCES. We can certainly revert back to only IMA_DATA_SOURCES to have an extra tab. "process_buffer_measurement()" change from void to int. This was also intentional, and was reviewed internally. The feedback was we should let the consumers of process_buffer_measurement() decide whether to use the return value or not. With void, we are not giving them any choice. scripts/Lindent isn't as prevalent as it used to be, but it's still included in Documentation/process/coding-style.rst. Use it as a guide. Thanks for the pointer. We'll use scripts/Lindent going forward. Mimi
