| Message ID | 20200812193102.18636-3-tusharsu@linux.microsoft.com (mailing list archive) |
|---|---|
| State | Superseded, archived |
| Delegated to: | Mike Snitzer |
| Headers | show |
| Series | IMA: Infrastructure for measurement of critical kernel data | expand |
On Wed, 2020-08-12 at 12:31 -0700, Tushar Sugandhi wrote: > There would be several candidate kernel components suitable for IMA > measurement. Not all of them would be enlightened for IMA measurement. > Also, system administrators may not want to measure data for all of > them, even when they are enlightened for IMA measurements. An IMA policy > specific to various kernel components is needed to measure their > respective critical data. > > Add a new IMA policy CRITICAL_DATA+data_sources to support measuring > various critical kernel components. This policy would enable the > system administrators to limit the measurement to the components, > if the components are enlightened for IMA measurement. "enlightened", really? Please find a different term, maybe something like "supported". Before posting a patch set, please look at the patches line by line, like anyone reviewing the code needs to do. Please minimize code change. Unnecessary formatting changes are unacceptible. For example, like the "#define", below, or in 3/3 the "process_buffer_measurement()" change from void to int. scripts/Lindent isn't as prevalent as it used to be, but it's still included in Documentation/process/coding-style.rst. Use it as a guide. Mimi -- dm-devel mailing list dm-devel@redhat.com https://www.redhat.com/mailman/listinfo/dm-devel
On 2020-08-17 1:43 p.m., Mimi Zohar wrote: > On Wed, 2020-08-12 at 12:31 -0700, Tushar Sugandhi wrote: >> There would be several candidate kernel components suitable for IMA >> measurement. Not all of them would be enlightened for IMA measurement. >> Also, system administrators may not want to measure data for all of >> them, even when they are enlightened for IMA measurements. An IMA policy >> specific to various kernel components is needed to measure their >> respective critical data. >> >> Add a new IMA policy CRITICAL_DATA+data_sources to support measuring >> various critical kernel components. This policy would enable the >> system administrators to limit the measurement to the components, >> if the components are enlightened for IMA measurement. > > "enlightened", really? Please find a different term, maybe something > like "supported". Thanks for the feedback Mimi. Will do. > > Before posting a patch set, please look at the patches line by line, > like anyone reviewing the code needs to do. Please minimize code > change. Unnecessary formatting changes are unacceptible. For > example, like the "#define", below, or in 3/3 the Thanks for the feedback Mimi. We extensively reviewed the patches internally before submitting for upstream review. We believed adding an extra tab was necessary so that all the previous values were aligned with the new one - #define IMA_DATA_SOURCES. We can certainly revert back to only IMA_DATA_SOURCES to have an extra tab. > "process_buffer_measurement()" change from void to int. > This was also intentional, and was reviewed internally. The feedback was we should let the consumers of process_buffer_measurement() decide whether to use the return value or not. With void, we are not giving them any choice. > scripts/Lindent isn't as prevalent as it used to be, but it's still > included in Documentation/process/coding-style.rst. Use it as a guide. Thanks for the pointer. We'll use scripts/Lindent going forward. > > Mimi > -- dm-devel mailing list dm-devel@redhat.com https://www.redhat.com/mailman/listinfo/dm-devel
On Mon, 2020-08-17 at 15:27 -0700, Tushar Sugandhi wrote: > > scripts/Lindent isn't as prevalent as it used to be, but it's still > > included in Documentation/process/coding-style.rst. Use it as a guide. > Thanks for the pointer. We'll use scripts/Lindent going forward Please don't change existing code to conform to it. Use it as a guide/suggestion for new code. Mimi -- dm-devel mailing list dm-devel@redhat.com https://www.redhat.com/mailman/listinfo/dm-devel
On 2020-08-17 4:43 p.m., Mimi Zohar wrote: > On Mon, 2020-08-17 at 15:27 -0700, Tushar Sugandhi wrote: > >>> scripts/Lindent isn't as prevalent as it used to be, but it's still >>> included in Documentation/process/coding-style.rst. Use it as a guide. >> Thanks for the pointer. We'll use scripts/Lindent going forward > > Please don't change existing code to conform to it. Use it as a > guide/suggestion for new code. > > Mimi > > Will do. Again, appreciate your feedback. -- dm-devel mailing list dm-devel@redhat.com https://www.redhat.com/mailman/listinfo/dm-devel
diff --git a/Documentation/ABI/testing/ima_policy b/Documentation/ABI/testing/ima_policy index cd572912c593..a0dd0f108555 100644 --- a/Documentation/ABI/testing/ima_policy +++ b/Documentation/ABI/testing/ima_policy @@ -29,7 +29,7 @@ Description: base: func:= [BPRM_CHECK][MMAP_CHECK][CREDS_CHECK][FILE_CHECK][MODULE_CHECK] [FIRMWARE_CHECK] [KEXEC_KERNEL_CHECK] [KEXEC_INITRAMFS_CHECK] - [KEXEC_CMDLINE] [KEY_CHECK] + [KEXEC_CMDLINE] [KEY_CHECK] [CRITICAL_DATA] mask:= [[^]MAY_READ] [[^]MAY_WRITE] [[^]MAY_APPEND] [[^]MAY_EXEC] fsmagic:= hex value @@ -125,3 +125,7 @@ Description: keys added to .builtin_trusted_keys or .ima keyring: measure func=KEY_CHECK keyrings=.builtin_trusted_keys|.ima + + Example of measure rule using CRITICAL_DATA to measure critical data + + measure func=CRITICAL_DATA data_sources=selinux|apparmor|dm-crypt diff --git a/security/integrity/ima/ima.h b/security/integrity/ima/ima.h index e2a151d6653d..99773dfa2541 100644 --- a/security/integrity/ima/ima.h +++ b/security/integrity/ima/ima.h @@ -200,6 +200,7 @@ static inline unsigned int ima_hash_key(u8 *digest) hook(POLICY_CHECK, policy) \ hook(KEXEC_CMDLINE, kexec_cmdline) \ hook(KEY_CHECK, key) \ + hook(CRITICAL_DATA, critical_data) \ hook(MAX_CHECK, none) #define __ima_hook_enumify(ENUM, str) ENUM, diff --git a/security/integrity/ima/ima_api.c b/security/integrity/ima/ima_api.c index af218babd198..9917e1730cb6 100644 --- a/security/integrity/ima/ima_api.c +++ b/security/integrity/ima/ima_api.c @@ -176,7 +176,7 @@ void ima_add_violation(struct file *file, const unsigned char *filename, * subj=, obj=, type=, func=, mask=, fsmagic= * subj,obj, and type: are LSM specific. * func: FILE_CHECK | BPRM_CHECK | CREDS_CHECK | MMAP_CHECK | MODULE_CHECK - * | KEXEC_CMDLINE | KEY_CHECK + * | KEXEC_CMDLINE | KEY_CHECK | CRITICAL_DATA * mask: contains the permission mask * fsmagic: hex value * diff --git a/security/integrity/ima/ima_policy.c b/security/integrity/ima/ima_policy.c index 4efaf8956eb8..8451ccb2a775 100644 --- a/security/integrity/ima/ima_policy.c +++ b/security/integrity/ima/ima_policy.c @@ -22,17 +22,18 @@ #include "ima.h" /* flags definitions */ -#define IMA_FUNC 0x0001 -#define IMA_MASK 0x0002 -#define IMA_FSMAGIC 0x0004 -#define IMA_UID 0x0008 -#define IMA_FOWNER 0x0010 -#define IMA_FSUUID 0x0020 -#define IMA_INMASK 0x0040 -#define IMA_EUID 0x0080 -#define IMA_PCR 0x0100 -#define IMA_FSNAME 0x0200 -#define IMA_KEYRINGS 0x0400 +#define IMA_FUNC 0x0001 +#define IMA_MASK 0x0002 +#define IMA_FSMAGIC 0x0004 +#define IMA_UID 0x0008 +#define IMA_FOWNER 0x0010 +#define IMA_FSUUID 0x0020 +#define IMA_INMASK 0x0040 +#define IMA_EUID 0x0080 +#define IMA_PCR 0x0100 +#define IMA_FSNAME 0x0200 +#define IMA_KEYRINGS 0x0400 +#define IMA_DATA_SOURCES 0x0800 #define UNKNOWN 0 #define MEASURE 0x0001 /* same as IMA_MEASURE */ @@ -84,6 +85,7 @@ struct ima_rule_entry { } lsm[MAX_LSM_RULES]; char *fsname; struct ima_rule_opt_list *keyrings; /* Measure keys added to these keyrings */ + struct ima_rule_opt_list *data_sources; /* Measure data from these sources */ struct ima_template_desc *template; }; @@ -508,14 +510,23 @@ static bool ima_match_rules(struct ima_rule_entry *rule, struct inode *inode, { int i; - if (func == KEY_CHECK) { - return (rule->flags & IMA_FUNC) && (rule->func == func) && - ima_match_rule_data(rule, rule->keyrings, func_data, - true, cred); - } if ((rule->flags & IMA_FUNC) && (rule->func != func && func != POST_SETATTR)) return false; + + switch (func) { + case KEY_CHECK: + return ((rule->func == func) && + ima_match_rule_data(rule, rule->keyrings, + func_data, true, cred)); + case CRITICAL_DATA: + return ((rule->func == func) && + ima_match_rule_data(rule, rule->data_sources, + func_data, false, cred)); + default: + break; + } + if ((rule->flags & IMA_MASK) && (rule->mask != mask && func != POST_SETATTR)) return false; @@ -911,7 +922,7 @@ enum { Opt_uid_lt, Opt_euid_lt, Opt_fowner_lt, Opt_appraise_type, Opt_appraise_flag, Opt_permit_directio, Opt_pcr, Opt_template, Opt_keyrings, - Opt_err + Opt_data_sources, Opt_err }; static const match_table_t policy_tokens = { @@ -948,6 +959,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} }; @@ -1110,6 +1122,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; @@ -1242,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) @@ -1312,6 +1339,23 @@ 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); @@ -1692,6 +1736,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);
There would be several candidate kernel components suitable for IMA measurement. Not all of them would be enlightened for IMA measurement. Also, system administrators may not want to measure data for all of them, even when they are enlightened for IMA measurements. An IMA policy specific to various kernel components is needed to measure their respective critical data. Add a new IMA policy CRITICAL_DATA+data_sources to support measuring various critical kernel components. This policy would enable the system administrators to limit the measurement to the components, if the components are enlightened for IMA measurement. Signed-off-by: Tushar Sugandhi <tusharsu@linux.microsoft.com> --- Documentation/ABI/testing/ima_policy | 6 +- security/integrity/ima/ima.h | 1 + security/integrity/ima/ima_api.c | 2 +- security/integrity/ima/ima_policy.c | 84 ++++++++++++++++++++++------ 4 files changed, 74 insertions(+), 19 deletions(-)