* IMA's use of the audit rule code [not found] <a6c15a35-a8cb-7589-7960-a19e788b6c45.ref@schaufler-ca.com> @ 2020-01-02 17:06 ` Casey Schaufler 2020-01-02 19:18 ` Mimi Zohar 0 siblings, 1 reply; 4+ messages in thread From: Casey Schaufler @ 2020-01-02 17:06 UTC (permalink / raw) To: Mimi Zohar, linux-integrity; +Cc: 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. ^ permalink raw reply [flat|nested] 4+ messages in thread
* Re: IMA's use of the audit rule code 2020-01-02 17:06 ` IMA's use of the audit rule code Casey Schaufler @ 2020-01-02 19:18 ` Mimi Zohar 2020-01-02 20:21 ` Casey Schaufler 0 siblings, 1 reply; 4+ messages in thread From: Mimi Zohar @ 2020-01-02 19:18 UTC (permalink / raw) To: Casey Schaufler, linux-integrity 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 ^ permalink raw reply [flat|nested] 4+ messages in thread
* Re: IMA's use of the audit rule code 2020-01-02 19:18 ` Mimi Zohar @ 2020-01-02 20:21 ` Casey Schaufler 2020-01-02 20:36 ` Mimi Zohar 0 siblings, 1 reply; 4+ messages in thread From: Casey Schaufler @ 2020-01-02 20:21 UTC (permalink / raw) To: Mimi Zohar, linux-integrity; +Cc: 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 > ^ permalink raw reply [flat|nested] 4+ messages in thread
* Re: IMA's use of the audit rule code 2020-01-02 20:21 ` Casey Schaufler @ 2020-01-02 20:36 ` Mimi Zohar 0 siblings, 0 replies; 4+ messages in thread From: Mimi Zohar @ 2020-01-02 20:36 UTC (permalink / raw) To: Casey Schaufler, linux-integrity 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 ^ permalink raw reply [flat|nested] 4+ messages in thread
end of thread, other threads:[~2020-01-02 20:37 UTC | newest]
Thread overview: 4+ messages (download: mbox.gz follow: Atom feed
-- links below jump to the message on this page --
[not found] <a6c15a35-a8cb-7589-7960-a19e788b6c45.ref@schaufler-ca.com>
2020-01-02 17:06 ` IMA's use of the audit rule code Casey Schaufler
2020-01-02 19:18 ` Mimi Zohar
2020-01-02 20:21 ` Casey Schaufler
2020-01-02 20:36 ` Mimi Zohar
This is an external index of several public inboxes, see mirroring instructions on how to clone and mirror all data and code used by this external index.