On Fri, Jan 24, 2020 at 5:32 PM Steve Grubb <[email protected]> wrote: > > Common Criteria calls out for any action that modifies the audit trail to > be recorded. That usually is interpreted to mean insertion or removal of > rules. It is not required to log modification of the inode information > since the watch is still in effect. Additionally, if the rule is a never > rule and the underlying file is one they do not want events for, they > get an event for this bookkeeping update against their wishes. > > Since no device/inode info is logged at insertion and no device/inode > information is logged on update, there is nothing meaningful being > communicated to the admin by the CONFIG_CHANGE updated_rules event. One > can assume that the rule was not "modified" because it is still watching > the intended target. If the device or inode cannot be resolved, then > audit_panic is called which is sufficient. > > The correct resolution is to drop logging config_update events since > the watch is still in effect but just on another unknown inode. > > Signed-off-by: Steve Grubb <[email protected]> > --- > kernel/audit_watch.c | 2 -- > 1 file changed, 2 deletions(-)
Much better. I've queued this up for audit/next, you'll see it in the tree once the merge window closes. > diff --git a/kernel/audit_watch.c b/kernel/audit_watch.c > index 4508d5e0cf69..8a8fd732ff6d 100644 > --- a/kernel/audit_watch.c > +++ b/kernel/audit_watch.c > @@ -302,8 +302,6 @@ static void audit_update_watch(struct audit_parent > *parent, > if (oentry->rule.exe) > audit_remove_mark(oentry->rule.exe); > > - audit_watch_log_rule_change(r, owatch, > "updated_rules"); > - > call_rcu(&oentry->rcu, audit_free_rule_rcu); > } > -- paul moore www.paul-moore.com -- Linux-audit mailing list [email protected] https://www.redhat.com/mailman/listinfo/linux-audit
