On Mon, 2020-12-28 at 20:53 -0500, Mimi Zohar wrote:

On Mon, 2020-12-28 at 15:20 -0800, Casey Schaufler wrote:

quoted

On 12/28/2020 2:14 PM, Mimi Zohar wrote:

quoted

On Mon, 2020-12-28 at 12:06 -0800, Casey Schaufler wrote:

quoted

On 12/28/2020 11:24 AM, Mimi Zohar wrote:

quoted

quoted

quoted

quoted

quoted

-int security_audit_rule_match(u32 secid, u32 field, u32 op, void *lsmrule)
+int security_audit_rule_match(u32 secid, u32 field, u32 op, void **lsmrule)
 {
-       return call_int_hook(audit_rule_match, 0, secid, field, op, lsmrule);
+       struct security_hook_list *hp;
+       int rc;
+
+       hlist_for_each_entry(hp, &security_hook_heads.audit_rule_match, list) {
+               if (WARN_ON(hp->lsmid->slot < 0 || hp->lsmid->slot >= lsm_slot))
+                       continue;
+               rc = hp->hook.audit_rule_match(secid, field, op,
+                                              &lsmrule[hp->lsmid->slot]);
+               if (rc)
+                       return rc;

Suppose that there is an IMA dont_measure or dont_appraise rule, if one
LSM matches, then this returns true, causing any measurement or
integrity verification to be skipped.

Yes, that is correct. Like the audit system, you're doing a string based
lookup, which pretty well has to work this way. I have proposed compound
label specifications in the past, but even if we accepted something like
"apparmor=dates,selinux=figs" we'd still have to be compatible with the
old style inputs.

quoted

Sample policy rules:
dont_measure obj_type=foo_log
dont_appraise obj_type=foo_log

IMA could extend the existing policy rules like "lsm=[selinux] |
[smack] | [apparmor]", but that assumes that the underlying
infrastructure supports it.

Yes, but you would still need rational behavior in the
case where someone has old IMA policy rules.

From an IMA perspective, allowing multiple LSMs to define the same
policy label is worse than requiring the label be constrained to a
particular LSM.

If allowing multiple LSMs to define the same label is only an IMA
issue, then have security_audit_rule_init() return the number of LSMs
which define the label.   IMA is already emitting a warning when an LSM
rule is not defined.   Emitting an additional warning would be the
first step.

In addition, ima_parse_rule() could detect policy rules containing non
LSM specific labels.  Based on policy, IMA would decide how to handle
it.

thanks,

Mimi