On Tue, Jan 7, 2020 at 5:52 PM Steve Grubb <[email protected]> wrote: > On Monday, January 6, 2020 8:47:33 PM EST Paul Moore wrote: > > On Sun, Jan 5, 2020 at 10:22 AM 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. > > > > > > 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. > > > > 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. -- paul moore www.paul-moore.com -- Linux-audit mailing list [email protected] https://www.redhat.com/mailman/listinfo/linux-audit
