audit: CONFIG_CHANGE don't log internal bookkeeping as an event
PATCH 1/1 audit: CONFIG_CHANGE don't log internal bookkeeping as an event
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.
I think 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
@@ -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
Paul Moore
maintainerQuoted 14 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_CHANGEupdated_rulesevent. 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, thenaudit_panicis called which is sufficient.
Quoted 2 lines
I think the correct resolution is to drop logging
config_updateevents since the watch is still in effect but just on another unknown inode.
Either this patch is the correct resolution or it isn't, the description should state that clearly. If you are unsure we can discuss it, but it sounds like you are certain that this record isn't needed here, yes?
Quoted 18 lines
Signed-off-by Steve Grubb <[email protected]>--- kernel/audit_watch.c | 2 -- 1 file changed, 2 deletions(-)kernel/audit_watch.c +0
-2@@ -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
Quoted 15 lines · EST Paul Moore
Quoted 14 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_CHANGEupdated_rulesevent. 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, thenaudit_panicis called which is sufficient.
Quoted 7 lines
Quoted 2 lines
I think the correct resolution is to drop logging
config_updateevents since the watch is still in effect but just on another unknown inode.Either this patch is the correct resolution or it isn't, the description should state that clearly. If you are unsure we can discuss it, but it sounds like you are certain that this record isn't needed here, yes?
It's not needed based on the rationale above and it's irritating some people because of that.
-Steve
Quoted 22 lines
Quoted 22 lines
Signed-off-by Steve Grubb <[email protected]>---
kernel/audit_watch.c | 2 -- 1 file changed, 2 deletions(-)kernel/audit_watch.c +0
-1@@ -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
maintainerQuoted 19 lines · Steve Grubb
Quoted 18 lines · EST Paul Moore
Quoted 16 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_CHANGEupdated_rulesevent. 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, thenaudit_panicis called which is sufficient.I think the correct resolution is to drop logging
config_updateevents since the watch is still in effect but just on another unknown inode.
Quoted 7 lines
Quoted 4 lines
Either this patch is the correct resolution or it isn't, the description should state that clearly. If you are unsure we can discuss it, but it sounds like you are certain that this record isn't needed here, yes?
It's not needed based on the rationale above and it's irritating some people because of that.
I didn't need you to repeat your conclusion, I needed you to rewrite your patch description to remove the ambiguity and resubmit :)
To be clear, the phrase "I think the correct resolution ..." is the problem; patches should be certain that their solution is correct.
Signature · 2 lines
paul moore www.paul-moore.com