On Thu, 2020-01-02 at 12:21 -0800, Casey Schaufler wrote: > On 1/2/2020 11:18 AM, Mimi Zohar wrote: > > On Thu, 2020-01-02 at 09:06 -0800, Casey Schaufler wrote: > >> IMA refines security_audit_rule_init to security_filter_rule_init. > >> I need to understand what, if any, relationship there is between > >> IMA's use of the audit rule mechanisms and the audit system's use. > >> Is this simple code reuse, or is there some interaction between IMA > >> and audit? > >> > >> I'm trying to sort out the problem of audit rules when > >> there are multiple security modules. It looks as if there is also a > >> problem for integrity rules, but it looks different. The "easy" > >> change for audit doesn't fit with what's in IMA. If there's no > >> interaction between the IMA and audit use of the rule infrastructure > >> it's reasonable to fix them separately. If there is interaction > >> things get messy. > > They're both comparing rules with LSM labels. In IMA's case, the LSM > > labels are used to identify which files are in/out of the IMA policy - > > "measurement", "appraisal", and "audit". I'm not sure how different > > this is than the audit subsystem. > > On a system that has both SELinux and Smack the audit admin might > want to set a rule on the label "system_u:object_r:something_t". > The LSM infrastructure can't tell if this is an SELinux label or a > Smack label, as it's valid for both. This is easily handled by > keeping an array of pointers for LSM checks, with a value set for > any module that wants to look for that label. > > IMA uses a very different data representation for its events than > audit does, making it much less obvious how to go about retaining > the security module to IMA event mapping. I'm looking at options. IMA converts the labels to an LSM value on initialization, or when the LSM policy is updated, by calling security_filter_rule_init(), a pseudonym for security_audit_rule_init(). I would assume audit is doing something similar. Mimi
