Skip to contentSkip to conversation

audit: CONFIG_CHANGE don't log internal bookkeeping as an event

PATCH Steve Grubb 2 participants 2 messages Jan 24, 2020 – Jan 31, 2020 Audit

lore
Share & tools
lore
#0 lore raw

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.

---
 kernel/audit_watch.c | 2 --
 1 file changed, 2 deletions(-)
kernel/audit_watch.c +0 -2
index 4508d5e0cf69..8a8fd732ff6d 100644
@@ -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);
 		}
 
Signature · 1 line
2.24.1
maintainer
#1 lore raw
Quoted 15 lines · Steve Grubb

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.

Quoted 7 lines

The correct resolution is to drop logging config_update events since the watch is still in effect but just on another unknown inode.

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

Quoted 13 lines
kernel/audit_watch.c +0 -2
index 4508d5e0cf69..8a8fd732ff6d 100644
@@ -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);
                }
 
Signature · 2 lines
paul moore
www.paul-moore.com