[PATCH 1/1] audit: CONFIG_CHANGE don't log internal bookkeeping as an event

[Paul Moore]

On Tue, Jan 7, 2020 at 5:52 PM Steve Grubb <sgrubb at redhat.com> 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 <sgrubb at redhat.com> 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