IMA's use of the audit rule code

IMA's use of the audit rule code

[Casey Schaufler]

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.

Re: IMA's use of the audit rule code

[Mimi Zohar]

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.

Mimi 

Re: IMA's use of the audit rule code

[Casey Schaufler]

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.

>
> Mimi 
>

Re: IMA's use of the audit rule code

[Mimi Zohar]

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