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

On Mon, 2020-12-28 at 15:20 -0800, Casey Schaufler wrote: > On 12/28/2020 2:14 PM, Mimi Zohar wrote: > > On Mon, 2020-12-28 at 12:06 -0800, Casey Schaufler wrote: > >> On 12/28/2020 11:24 AM, Mimi Zohar wrote:

> >>>> -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.