Re: [PATCH v23 02/23] LSM: Create and manage the lsmblob data structure.

>>>>>> -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. >>>> >>>>> 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. Just to be sure we're talking about the same thing, the case I'm referring to is something like a file with two extended attributes: security.apparmor MacAndCheese security.SMACK64 MacAndCheese and an IMA rule that says dont_measure obj_type=MacAndCheese In this case the dont_measure will be applied to both. On the other hand, security.apparmor MacAndCheese security.SMACK64 FranksAndBeans would also apply the rule to both, which is not what you want. Unfortunately, there is no way to differentiate which LSM hit the rule. So now I'm a little confused. The case where both LSMs use the same label looks like it works right, where the case where they're different doesn't.

I'm beginning to think that identifying which LSMs matched a rule (it may be none, either or both) is the right solution. I don't think that audit is as sensitive to this.