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
[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(_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 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
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
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
[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(_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 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
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(_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 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 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
[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 = _eq;
entry->fowner_op = _eq;
entry->action = UNKNOWN;
+ entry->allow_dup = false;
while ((p = strsep(, " \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:
ima_log_s
[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
[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 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, );
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, ,
- _desc, NULL);
+ _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, );
inode = file_inode(vma->vm_file);
action = ima_get_action(inode, current_cred(), secid, MAY_EXEC,
-
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 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 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) {
+
[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(_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 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 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 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 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
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 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
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 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 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 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 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 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
function
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. Will f
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, );
action = ima_get_action(inode, current_cred(), secid, 0, func,
- , , keyring);
+ , , 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_entry *rule, struct inode *inode,
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 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
[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
[PATCH v9 0/8] IMA: support for measuring kernel integrity critical data
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 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_data) +
[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:
[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
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
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
[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 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 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
[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
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 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 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
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.
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 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 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 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 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 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, const ch
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_hooks
[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
[PATCH v7 0/8] IMA: support for measuring kernel integrity critical 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 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 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 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
[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) +
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 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
[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
[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 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 +-
[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 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
[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_queue_keys.c
Re: [PATCH v5 3/7] IMA: add hook to measure critical data
Including "data_source" here isn't quite right. "data source" should only be added in the first patch which uses it, not here. When adding it please shorten the field description to "kernel data source". The longer explanation can be included in the longer function description. *Question* Do you mean the parameter @event_data_source should be removed from this patch? And then later added in patch 7/7 – where SeLinux uses it? Data source support doesn't belong in this patch. Each patch should do one logical thing and only that one thing. This patch is adding support for measuring critical data. The data source patch will limit the critical data being measured. Other than updating the data source list in the documentation, definitely do not add data source support to the SELinux patch. thanks, Mimi Makes sense, I will move the data_source from this patch to a separate one before SeLinux. And the SeLinux patch will simply update the documentation. Thanks Mimi.
Re: [PATCH v5 2/7] IMA: update process_buffer_measurement to measure buffer hash
On 2020-11-12 2:19 p.m., Mimi Zohar wrote: On Thu, 2020-11-12 at 13:47 -0800, Tushar Sugandhi wrote: On Sun, 2020-11-01 at 14:26 -0800, Tushar Sugandhi wrote: process_buffer_measurement() currently only measures the input buffer. In case of SeLinux policy measurement, the policy being measured could be large (several MB). This may result in a large entry in IMA measurement log. SELinux is an example of measuring large buffer data. Please rewrite this patch description (and the other patch descriptions in this patch set) without using the example to describe its purpose [1]. In this case, you might say, The original IMA buffer data measurement sizes were small (e.g. boot command line), but new buffer data measurement use cases are a lot larger. Just as IMA measures the file data hash, not the file data, IMA should similarly support measuring the buffer data hash. Sure. Thanks a lot for giving an example wording for us. Will update. Introduce a boolean parameter measure_buf_hash to support measuring hash of a buffer, which would be much smaller, instead of the buffer itself. To use the functionality introduced in this patch, the attestation client and the server changes need to go hand in hand. The client/kernel would know what data is being measured as-is (e.g. KEXEC_CMDLINE), and what data has it’s hash measured (e.g. SeLinux Policy). And the attestation server should verify data/hash accordingly. Just like the data being measured in other cases, the attestation server will know what are possible values of the large buffers being measured. e.g. the possible valid SeLinux policy values that are being pushed to the client. The attestation server will have to maintain the hash of those buffer values. Each patch in the patch set builds upon the previous one. (Think of it as a story, where each chapter builds upon the previous ones.) With rare exceptions, should patches reference subsequent patches. [2] [1] Refer to Documentation/process/submitting-patches.rst [2] Refer to the section "8) Commenting" in Documentation/process/coding-style.rst I am not sure if you have any concerns about the last two paragraphs. The description about the attestation client and server (the last two paragraphs) was added for information/clarification purpose only, as per your feedback on previous iterations. The subsequent patches don’t have any code pertaining to attestation client/server. *Question* Maybe the last two paragraphs are confusing/redundant. Could you please let me know if I should remove the above two paragraphs altogether? (starting with “To use the functionality introduced in this patch ...”) If we decide to keep the paragraphs, I will remove the specific examples (KEXEC_CMDLINE, SeLinux etc.) as you mentioned elsewhere. Instead of the above two paragraphs, perhaps explain how measuring the file data hash differs from measuring the buffer data hash. Keep the explanation generic, short and simple. Mimi Will do. Thanks for the quick response Mimi. I also have some clarification questions on the other patches in this series as well. Would really appreciate if you could help us get clarification on those. Thanks a lot again. ~Tushar
Re: [PATCH v5 0/7] IMA: Infrastructure for measurement of critical kernel data
On 2020-11-04 4:31 p.m., Mimi Zohar wrote: Hi Tushar, Measuring "critical kernel data" is not a new infrastructure, simply a new IMA hook. Please update the above Subject line to "support for measuring critical kernel data". Thanks a lot. Will update. On Sun, 2020-11-01 at 14:26 -0800, Tushar Sugandhi wrote: There are several kernel subsystems that contain critical data which if accidentally or maliciously altered, can compromise the integrity of the system. Examples of such subsystems would include LSMs like SELinux, or AppArmor; or device-mapper targets like dm-crypt, dm-verity etc. "critical data" in this context is kernel subsystem specific information that is stored in kernel memory. 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 is a bit better, but needs to be much clearer. Please define "critical data", not by example, but by describing "what" critical kernel data is. "There are several kernel subsystems " is an example of "how" it would be used, not a definition. Without a clear definition it will become a dumping ground for measuring anything anyone wants to measure. As a result, it may be abused. Good point. I will come up with a better definition. This patch set defines a new IMA hook namely CRITICAL_DATA, and a function ima_measure_critical_data() - to measure the critical data. The name of the IMA hook is ima_measure_critical_data. This is similar to the LSM hooks, which are prefixed with "security_". (For a full list of LSM hooks, refer to lsm_hook_defs.h.) Thanks for the clarification. I will update this description. 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 of any kernel subsystem at run-time. To ensure that only data from supported sources are measured, the kernel subsystem 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. Yes, this new feature is generic, but one of the main goals of IMA is to measure and attest to the integrity of the system, not to measure and attest to random things. Ok. I will update the above paragraph accordingly. System administrators may want to pick and choose which kernel subsystem information they would want to enable for measurements, quoting, and remote attestation. To enable that, a new IMA policy is introduced. ^may want to limit the critical data being measured, quoted and attested. ^ a new IMA policy condition is defined. Sounds good. Will update. This patch set also addresses the need for the kernel subsystems to measure their data before a custom IMA policy is loaded - by providing a builtin IMA policy. ^for measuring kernel critical data early, before a custom IMA policy ... Sounds good. Will update. And lastly, the use of the overall functionality is demonstrated by measuring the kernel in-memory data for one such subsystem - SeLinux. The purpose isn't to demonstrate the "overall functionality", but to provide an initial caller of the new IMA hook. Fair point. Will change the description accordingly. ~Tushar thanks, Mimi
Re: [PATCH v5 5/7] IMA: validate supported kernel data sources before measurement
On 2020-11-06 6:01 a.m., Mimi Zohar wrote: Hi Tushar, On Sun, 2020-11-01 at 14:26 -0800, Tushar Sugandhi wrote: 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+data_sources. To ensure that only data from supported sources are measured, the kernel subsystem name needs to be added to a compile-time list of supported sources (an "allowed list of components"). IMA then validates the input parameter - "event_data_source" passed to ima_measure_critical_data() against this allowed list at run-time. This compile-time list must be updated when kernel subsystems are updated to measure their data using IMA. Provide an infrastructure for kernel data sources to be added to IMA's 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 coming from that source. For those interested in limiting which critical data to measure, the "data sources" IMA policy rule option already does that. Why is this needed? thanks, Mimi This wasn’t part of the initial series. And I wasn’t convinced if it was really needed. :) I added it based on the feedback in v2 of this series. (pasted below for reference[1]). Maybe I misunderstood your feedback at that time. *Question* Could you please let me know if you want us to remove this patch? [1] From v2 of this series: https://patchwork.kernel.org/project/linux-integrity/patch/20200821182107.5328-3-tusha...@linux.microsoft.com/ >>>> "keyrings=" isn't bounded because keyrings can be created by userspace. >>>> Perhaps keyring names has a minimum/maximum length. IMA isn't >>>> measuring userspace construsts. Shouldn't the list of critical data >>>> being measured be bounded and verified? >>> The comment is not entirely clear. >>> Do you mean there should be some sort of allow_list in IMA, against >>> which the values in "data_sources=" should be vetted? And if the >>> value is present in the IMA allow_list, then only the measurements for >>> that data source are allowed? >>> >>> Or do you mean something else? >> >> Yes, something along those lines. Does the list of critical data need >> to be vetted? And if so, against what? > I am thinking of having an enum and string array - just like ima_hooks > and ima_hooks_measure_str in ima.h. > And any new kernel component that would support generic IMA measurements > in future would have to add itself to the enum/array. > And the param *event_data_source in ima_measure_critical_data() will be > vetted against the above enum/string array. > > I will implement it in the next iteration, and hopefully the vetting > workflow will be more clear. > > ~Tushar >> >> Mimi
Re: [PATCH v5 4/7] IMA: add policy to measure critical data
On 2020-11-06 5:43 a.m., Mimi Zohar wrote:
Hi Tushar,
On Sun, 2020-11-01 at 14:26 -0800, Tushar Sugandhi wrote:
System administrators should be able to choose which kernel subsystems
they want to measure the critical data for. To enable that, an IMA policy
option to choose specific kernel subsystems is needed. This policy option
would constrain the measurement of the critical data to the given kernel
subsystems.
Measuring critical data should not be dependent on the source of the
critical data. This patch needs to be split up. The "data sources"
should be move to it's own separate patch. This patch should be
limited to adding the policy code needed for measuring criticial data.
Limiting critical data sources should be the last patch in this series.
thanks,
Mimi
Thanks Mimi.
Ok. I will split the patches as you suggested.
Patch #1 (this patch) will have the policy code needed for measuring
critical data.
patch #2 Limiting the critical “data_sources”.
*Question 1*
Since you said patch #2 should be the last patch in this series, do you
mean merging patch #2 with the SeLinux patch? (patch 7/7 of this series)
Or a separate patch before 7/7?
*Question 2*
If I understand it correctly, the following code should be moved from
this patch to patch #2. Did I miss anything?
static const match_table_t policy_tokens = {
@@ -957,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}
};
+ 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;
+ if (entry->flags & IMA_DATA_SOURCES) {
+ seq_puts(m, "data_sources=");
+ ima_show_rule_opt_list(m, entry->data_sources);
+ seq_puts(m, " ");
+ }
+
~Tushar
Add a new IMA policy option - "data_sources:=" to the IMA func
CRITICAL_DATA to allow measurement of various kernel subsystems. This
policy option would enable the system administrators to limit the
measurement to the subsystems listed in "data_sources:=", if the
subsystem measures its data by calling ima_measure_critical_data().
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, measure the data from all the
supported kernel subsystems.
Signed-off-by: Tushar Sugandhi
Re: [PATCH v5 3/7] IMA: add hook to measure critical data
On 2020-11-06 5:24 a.m., Mimi Zohar wrote: Hi Tushar, On Sun, 2020-11-01 at 14:26 -0800, Tushar Sugandhi wrote: Currently, IMA does not provide a generic function for kernel subsystems to measure their critical data. Examples of critical data in this context could be kernel in-memory r/o structures, hash of the memory structures, or data that represents a linux kernel subsystem state change. The critical data, if accidentally or maliciously altered, can compromise the integrity of the system. Start out with what IMA does do (e.g. measures files and more recently buffer data). Afterwards continue with kernel integrity critical data should also be measured. Please include a definition of kernel integrity critical data here, as well as in the cover letter. Yes, will do. I will also describe what kernel integrity critical data is – by providing a definition, and not by example - as you suggested. (here and in the cover letter) A generic function provided by IMA to measure critical data would enable various subsystems with easier and faster on-boarding to use IMA infrastructure and would also avoid code duplication. By definition LSM and IMA hooks are generic with callers in appropriate places in the kernel. This paragraph is redundant. Sounds good. I will remove this paragraph. Add a new IMA func CRITICAL_DATA and a corresponding IMA hook ima_measure_critical_data() to support measuring critical data for various kernel subsystems. Instead of using the word "add", it would be more appropriate to use the word "define". Define a new IMA hook named ima_measure_critical_data to measure kernel integrity critical data. Please also update the Subject line as well. "ima: define an IMA hook to measure kernel integrity critical data". Sounds good. Will do. Signed-off-by: Tushar Sugandhi --- diff --git a/security/integrity/ima/ima_main.c b/security/integrity/ima/ima_main.c index 4485d87c0aa5..6e1b11dcba53 100644 --- a/security/integrity/ima/ima_main.c +++ b/security/integrity/ima/ima_main.c @@ -921,6 +921,44 @@ void ima_kexec_cmdline(int kernel_fd, const void *buf, int size) fdput(f); } +/** + * ima_measure_critical_data - measure kernel subsystem data + * critical to integrity of the kernel Please change this to "measure kernel integrity critical data". *Question* Thanks Mimi. Do you want us just to update the description, or do you want us to update the function name too? I believe you meant just description, but still want to clarify. ima_measure_kernel_integrity_critical_data() would be too long. Maybe ima_measure_integrity_critical_data()? Or do you want us to keep the existing ima_measure_critical_data()? Could you please let us know? + * @event_data_source: name of the data source being measured; + * typically it should be the name of the kernel subsystem that is sending + * the data for measurement Including "data_source" here isn't quite right. "data source" should only be added in the first patch which uses it, not here. When adding it please shorten the field description to "kernel data source". The longer explanation can be included in the longer function description. *Question* Do you mean the parameter @event_data_source should be removed from this patch? And then later added in patch 7/7 – where SeLinux uses it? But ima_measure_critical_data() calls process_buffer_measurement(), and p_b_m() accepts it as part of the param @func_data. What should we pass to p_b_m() @func_data in this patch, if we remove @event_data_source from this patch? + * @event_name: name of an event from the kernel subsystem that is sending + * the data for measurement As this is being passed to process_buffer_measurement(), this should be the same or similar to the existing definition. Ok. I will change this to @eventname to be consistemt with p_b_m(). + * @buf: pointer to buffer containing data to measure + * @buf_len: length of buffer(in bytes) + * @measure_buf_hash: if set to true - will measure hash of the buf, + *instead of buf kernel doc requires a single line. In this case, please shorten the argument definition to "measure buffer data or buffer data hash". The details can be included in the longer function description. Sounds good. Will do. + * + * A given kernel subsystem (event_data_source) may send + * data (buf) to be measured when the data or the subsystem state changes. + * The state/data change can be described by event_name. + * Examples of critical data (buf) could be kernel in-memory r/o structures, + * hash of the memory structures, or data that represents subsystem + * state change. + * 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. + */ Please remove this longer function description, replacing it something more appropriate
Re: [PATCH v5 2/7] IMA: update process_buffer_measurement to measure buffer hash
On 2020-11-06 4:11 a.m., Mimi Zohar wrote:
Hi Tushar,
Below inline are a few additional comments.
diff --git a/security/integrity/ima/ima_main.c
b/security/integrity/ima/ima_main.c
index ae5da9f3339d..4485d87c0aa5 100644
--- a/security/integrity/ima/ima_main.c
+++ b/security/integrity/ima/ima_main.c
@@ -787,12 +787,15 @@ 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: if set to true - will measure hash of the buf,
+ *instead of buf
*
* Based on policy, the buffer is measured into the ima log.
Both the brief and longer function descriptions need to be updated, as
well as the last argument description. The last argument should be
limited to "measure buffer hash". How it is used could be included in
the longer function description. The longer function description would
include adding the buffer data or the buffer data hash to the IMA
measurement list and extending the PCR.
For example,
process_buffer_measurement - measure the buffer data or the buffer data
hash
Thanks Mimi. Will update the brief and longer descriptions accordingly.
*/
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 +810,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 hash_len = hash_digest_size[ima_hash_algo];
int violation = 0;
int action = 0;
u32 secid;
@@ -855,6 +860,21 @@ void process_buffer_measurement(struct inode *inode, const
void *buf, int size,
goto out;
}
+ if (measure_buf_hash) {
+ memcpy(digest_hash, hash.hdr.digest, hash_len);
Instead of digest_hash and hash_len, consider naming the variables
buf_hash and buf_hashlen.
Thanks. Will do.
+
+ ret = ima_calc_buffer_hash(digest_hash,
+ hash_len,
+ iint.ima_hash);
There's no need for each variable to be on a separate line.
Thanks, will fix.
~Tushar
thanks,
Mimi
+ if (ret < 0) {
+ audit_cause = "measure_buf_hash_error";
+ goto out;
+ }
+
+ event_data.buf = digest_hash;
+ event_data.buf_len = hash_len;
+ }
+
ret = ima_alloc_init_template(_data, , template);
if (ret < 0) {
audit_cause = "alloc_entry";
Re: [PATCH v5 2/7] IMA: update process_buffer_measurement to measure buffer hash
Hello Mimi, On 2020-11-05 6:30 a.m., Mimi Zohar wrote: Hi Tushar, Please don't include the filename in the Subject line[1]. The Subject line should be a summary phrase describing the patch. In this case, it is adding support for measuring the buffer data hash. Thanks. Will update the subject line accordingly. On Sun, 2020-11-01 at 14:26 -0800, Tushar Sugandhi wrote: process_buffer_measurement() currently only measures the input buffer. In case of SeLinux policy measurement, the policy being measured could be large (several MB). This may result in a large entry in IMA measurement log. SELinux is an example of measuring large buffer data. Please rewrite this patch description (and the other patch descriptions in this patch set) without using the example to describe its purpose [1]. In this case, you might say, The original IMA buffer data measurement sizes were small (e.g. boot command line), but new buffer data measurement use cases are a lot larger. Just as IMA measures the file data hash, not the file data, IMA should similarly support measuring the buffer data hash. Sure. Thanks a lot for giving an example wording for us. Will update. Introduce a boolean parameter measure_buf_hash to support measuring hash of a buffer, which would be much smaller, instead of the buffer itself. To use the functionality introduced in this patch, the attestation client and the server changes need to go hand in hand. The client/kernel would know what data is being measured as-is (e.g. KEXEC_CMDLINE), and what data has it’s hash measured (e.g. SeLinux Policy). And the attestation server should verify data/hash accordingly. Just like the data being measured in other cases, the attestation server will know what are possible values of the large buffers being measured. e.g. the possible valid SeLinux policy values that are being pushed to the client. The attestation server will have to maintain the hash of those buffer values. Each patch in the patch set builds upon the previous one. (Think of it as a story, where each chapter builds upon the previous ones.) With rare exceptions, should patches reference subsequent patches. [2] [1] Refer to Documentation/process/submitting-patches.rst [2] Refer to the section "8) Commenting" in Documentation/process/coding-style.rst thanks, Mimi I am not sure if you have any concerns about the last two paragraphs. The description about the attestation client and server (the last two paragraphs) was added for information/clarification purpose only, as per your feedback on previous iterations. The subsequent patches don’t have any code pertaining to attestation client/server. *Question* Maybe the last two paragraphs are confusing/redundant. Could you please let me know if I should remove the above two paragraphs altogether? (starting with “To use the functionality introduced in this patch ...”) If we decide to keep the paragraphs, I will remove the specific examples (KEXEC_CMDLINE, SeLinux etc.) as you mentioned elsewhere.
[PATCH v5 4/7] IMA: add policy to measure critical data
System administrators should be able to choose which kernel subsystems
they want to measure the critical data for. To enable that, an IMA policy
option to choose specific kernel subsystems is needed. This policy option
would constrain the measurement of the critical data to the given kernel
subsystems.
Add a new IMA policy option - "data_sources:=" to the IMA func
CRITICAL_DATA to allow measurement of various kernel subsystems. This
policy option would enable the system administrators to limit the
measurement to the subsystems listed in "data_sources:=", if the
subsystem measures its data by calling ima_measure_critical_data().
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, measure the data from all the
supported kernel subsystems.
Signed-off-by: Tushar Sugandhi
---
Documentation/ABI/testing/ima_policy | 4 ++
security/integrity/ima/ima_policy.c | 62 +---
2 files changed, 61 insertions(+), 5 deletions(-)
diff --git a/Documentation/ABI/testing/ima_policy
b/Documentation/ABI/testing/ima_policy
index 3de6c774c37e..15be8b16f6f3 100644
--- a/Documentation/ABI/testing/ima_policy
+++ b/Documentation/ABI/testing/ima_policy
@@ -48,6 +48,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 f48e82450fe1..ec99e0bb6c6f 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;
@@ -920,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 = {
@@ -957,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}
};
@@ -1119,6 +1134,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;
[PATCH v5 0/7] IMA: Infrastructure for measurement of critical kernel data
xisting #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. Lakshmi Ramasubramanian (2): IMA: add critical_data to the built-in policy rules selinux: measure state and hash of the policy using IMA Tushar Sugandhi (5): IMA: generalize keyring specific measurement constructs IMA: update process_buffer_measurement to measure buffer hash IMA: add hook to measure critical data IMA: add policy to measure critical data IMA: validate supported kernel data sources before measurement Documentation/ABI/testing/ima_policy | 10 +- include/linux/ima.h | 8 + security/integrity/ima/ima.h | 38 - 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| 79 +- security/integrity/ima/ima_policy.c | 143 ++--- security/integrity/ima/ima_queue_keys.c | 3 +- security/selinux/Makefile| 2 + security/selinux/hooks.c | 3 + security/selinux/include/security.h | 11 +- security/selinux/measure.c | 157 +++ security/selinux/selinuxfs.c | 9 ++ security/selinux/ss/services.c | 71 +++-- 15 files changed, 499 insertions(+), 47 deletions(-) create mode 100644 security/selinux/measure.c -- 2.17.1
[PATCH v5 2/7] IMA: update process_buffer_measurement to measure buffer hash
process_buffer_measurement() currently only measures the input buffer.
In case of SeLinux policy measurement, the policy being measured could
be large (several MB). This may result in a large entry in IMA
measurement log.
Introduce a boolean parameter measure_buf_hash to support measuring
hash of a buffer, which would be much smaller, instead of the buffer
itself.
To use the functionality introduced in this patch, the attestation
client and the server changes need to go hand in hand. The
client/kernel would know what data is being measured as-is
(e.g. KEXEC_CMDLINE), and what data has it’s hash measured (e.g. SeLinux
Policy). And the attestation server should verify data/hash accordingly.
Just like the data being measured in other cases, the attestation server
will know what are possible values of the large buffers being measured.
e.g. the possible valid SeLinux policy values that are being pushed to
the client. The attestation server will have to maintain the hash of
those buffer values.
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| 25 ++--
security/integrity/ima/ima_queue_keys.c | 3 ++-
5 files changed, 29 insertions(+), 6 deletions(-)
diff --git a/security/integrity/ima/ima.h b/security/integrity/ima/ima.h
index 8875085db689..0f77e0b697a3 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);
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 ae5da9f3339d..4485d87c0aa5 100644
--- a/security/integrity/ima/ima_main.c
+++ b/security/integrity/ima/ima_main.c
@@ -787,12 +787,15 @@ 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: if set to true - will measure hash of the buf,
+ *instead of buf
*
* 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 pcr, const char *func_data,
+ bool measure_buf_hash)
{
int ret = 0;
const char *audit_cause = "ENOMEM";
@@ -807,6 +810,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 hash_len = hash_digest_size[ima_hash_algo];
int violation = 0;
int action = 0;
u32 secid;
@@ -855,6 +860,
[PATCH v5 3/7] IMA: add hook to measure critical data
Currently, IMA does not provide a generic function for kernel subsystems
to measure their critical data. Examples of critical data in this context
could be kernel in-memory r/o structures, hash of the memory structures,
or data that represents a linux kernel subsystem state change. The
critical data, if accidentally or maliciously altered, can compromise
the integrity of the system.
A generic function provided by IMA to measure critical data would enable
various subsystems with easier and faster on-boarding to use IMA
infrastructure and would also avoid code duplication.
Add a new IMA func CRITICAL_DATA and a corresponding IMA hook
ima_measure_critical_data() to support measuring critical data for
various kernel subsystems.
Signed-off-by: Tushar Sugandhi
---
Documentation/ABI/testing/ima_policy | 2 +-
include/linux/ima.h | 8 ++
security/integrity/ima/ima.h | 1 +
security/integrity/ima/ima_api.c | 2 +-
security/integrity/ima/ima_main.c| 38
security/integrity/ima/ima_policy.c | 2 ++
6 files changed, 51 insertions(+), 2 deletions(-)
diff --git a/Documentation/ABI/testing/ima_policy
b/Documentation/ABI/testing/ima_policy
index cd572912c593..3de6c774c37e 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
diff --git a/include/linux/ima.h b/include/linux/ima.h
index 8fa7bcfb2da2..60ba073f1575 100644
--- a/include/linux/ima.h
+++ b/include/linux/ima.h
@@ -30,6 +30,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 void ima_measure_critical_data(const char *event_data_source,
+ 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 +120,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_data_source,
+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 0f77e0b697a3..c1acf88e1b5d 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_main.c
b/security/integrity/ima/ima_main.c
index 4485d87c0aa5..6e1b11dcba53 100644
--- a/security/integrity/ima/ima_main.c
+++ b/security/integrity/ima/ima_main.c
@@ -921,6 +921,44 @@ void ima_kexec_cmdline(int kernel_fd, const void *buf, int
size)
fdput(f);
}
+/**
+ * ima_measure_critical_data - measure kernel subsystem data
+ * critical to integrity of the kernel
+ * @event_data_source: name of the data source being measured;
+ * typically it should be the name of the kernel subsystem that is sending
[PATCH v5 5/7] 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+data_sources.
To ensure that only data from supported sources are measured, the kernel
subsystem name needs to be added to a compile-time list of supported
sources (an "allowed list of components"). IMA then validates the input
parameter - "event_data_source" passed to ima_measure_critical_data()
against this allowed list at run-time.
This compile-time list must be updated when kernel subsystems are
updated to measure their data using IMA.
Provide an infrastructure for kernel data sources to be added to
IMA's 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 coming from that source.
Signed-off-by: Tushar Sugandhi
---
security/integrity/ima/ima.h | 29 +
security/integrity/ima/ima_main.c | 12
2 files changed, 41 insertions(+)
diff --git a/security/integrity/ima/ima.h b/security/integrity/ima/ima.h
index c1acf88e1b5d..4a35db010d91 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 6e1b11dcba53..091c2e58f3c7 100644
--- a/security/integrity/ima/ima_main.c
+++ b/security/integrity/ima/ima_main.c
@@ -937,6 +937,12 @@ void ima_kexec_cmdline(int kernel_fd, const void *buf, int
size)
* A given kernel subsystem (event_data_source) may send
* data (buf) to be measured when the data or the subsystem state changes.
* The state/data change can be described by event_name.
+ * Before the first use of this function by a given kernel subsystem,
+ * the subsystem name (event_data_source) must be added to the
+ * compile-time list of data sources being measured -
+ * i.e. __ima_supported_kernel_data_sources.
+ * Otherwise, IMA will not measure any data for that event_data_source
+ * at run-time.
* Examples of critical data (buf) could be kernel in-memory r/o structures,
* hash of the memory structures, or data that represents subsystem
* state change.
@@ -954,6 +960,12 @@ void ima_measure_critical_data(const char
*event_data_source,
return;
}
+ if (!ima_kernel_data_source_is_supported(event_data_source)) {
+ pr_err("measuring data source %s is not permitted",
+ event_data_source);
+ return;
+ }
+
process_buffer_measurement(NULL, buf, buf_len, event_name,
CRITICAL_DATA, 0, event_data_source,
measure_buf_hash);
--
2.17.1
[PATCH v5 6/7] IMA: add critical_data to the built-in policy rules
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. For example, SELinux calls ima_measure_critical_data() to
measure its state and policy when they are initialized. This occurs
before a custom IMA policy is loaded, and hence IMA hook will not
measure the data. A built-in policy is therefore needed to measure
critical data provided by callers 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". Set the IMA template for this rule
to "ima-buf" since ima_measure_critical_data() measures a buffer.
Signed-off-by: Lakshmi Ramasubramanian
---
security/integrity/ima/ima_policy.c | 32 +
1 file changed, 32 insertions(+)
diff --git a/security/integrity/ima/ima_policy.c
b/security/integrity/ima/ima_policy.c
index ec99e0bb6c6f..dc8fe969d3fe 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
@@ -813,6 +820,8 @@ static int __init ima_init_arch_policy(void)
void __init ima_init_policy(void)
{
int build_appraise_entries, arch_entries;
+ struct ima_template_desc *template = NULL;
+ int ret = 0;
/* if !ima_policy, we load NO default rules */
if (ima_policy)
@@ -875,6 +884,29 @@ void __init ima_init_policy(void)
ARRAY_SIZE(default_appraise_rules),
IMA_DEFAULT_POLICY);
+ if (ima_use_critical_data) {
+ template = lookup_template_desc("ima-buf");
+ if (!template) {
+ ret = -EINVAL;
+ goto out;
+ }
+
+ ret = template_desc_init_fields(template->fmt,
+ &(template->fields),
+ &(template->num_fields));
+ if (ret)
+ goto out;
+
+ critical_data_rules[0].template = template;
+ add_rules(critical_data_rules,
+ ARRAY_SIZE(critical_data_rules),
+ IMA_DEFAULT_POLICY);
+ }
+
+out:
+ if (ret)
+ pr_err("%s failed, result: %d\n", __func__, ret);
+
ima_update_policy_flag();
}
--
2.17.1
[PATCH v5 7/7] selinux: measure state and hash of the policy using IMA
From: Lakshmi Ramasubramanian Critical data structures of security modules are currently not measured. Therefore an attestation service, for instance, would not be able to attest whether the security modules are always operating with the policies and configurations that the system administrator had setup. The policies and configurations for the security modules could be tampered by rogue user mode agents or modified through some inadvertent actions on the system. Measuring such critical data would enable an attestation service to reliably assess the security configuration 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/integrity/ima/ima.h | 1 + security/selinux/Makefile| 2 + security/selinux/hooks.c | 3 + security/selinux/include/security.h | 11 +- security/selinux/measure.c | 157 +++ security/selinux/selinuxfs.c | 9 ++ security/selinux/ss/services.c | 71 ++-- 8 files changed, 249 insertions(+), 11 deletions(-) create mode 100644 security/selinux/measure.c diff --git a/Documentation/ABI/testing/ima_policy
[PATCH v5 1/7] 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 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 2d1af8899cab..ae5da9f3339d 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";
@@ -824,7 +824,7 @@ void process_buffer_measurement(struct inode *inode, const
Re: [PATCH v4 0/6] IMA: Infrastructure for measurement of critical kernel data
Hi Mimi,
Thanks a lot for your continual engagement and
providing us valuable feedback on this work.
On 2020-10-24 8:35 p.m., Mimi Zohar wrote:
Hi Tushar,
On Wed, 2020-09-23 at 12:20 -0700, Tushar Sugandhi wrote:
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.
^"the integrity of the system."
Ok. I will revisit this cover letter again, when we post the next
version of the series. We also need to update the cover letter to
include the description for new patches to be added in this series, as
per your suggestion below. {built-in policy patch (by Lakshmi) and an
example measurement patch (SeLinux by Lakshmi)}
This cover letter needs to be re-written from a higher perspective,
explaining what is meant by "critical data" (e.g. kernel subsystem
specific information only stored in kernel memory).
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.
True, up until recently IMA only measured files, nothing else. Why is
this paragraph needed? What new information is provided?
Here, I was attempting to describe the problem (what needs to be
solved), before proposing a solution below. But maybe it is not adding
value. I will get rid of the above paragraph in the next iteration.
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.
Perhaps, something more along the lines, "This patch set defines a new
IMA hook named ... to measure critical data."
Will do.
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.
Reverse the order of this paragraph and the following one, describing
the new feature and only afterwards explaining how it may be
constrained.
Makes total sense. Will do.
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 patch set must include at least one example of measuring critical
data, before it can be upstreamed. Tushar, please coordinate with
Lakshmi and Raphael.
Yes. I am coordinating with Lakshmi/Raphael on including one of the
examples. (SeLinux as per your feedback)
BTW, we also have one more data source (dm-crypt) currently in review,
that uses critical data measurement infrastructure to measure its kernel
in-memory data.
https://patchwork.kernel.org/patch/11844817/
Thanks again for all the help and support with the patches.
~Tushar
thanks,
Mimi
