On Fri, Nov 19, 2021 at 1:02 PM Richard Guy Briggs <rgb(a)redhat.com> wrote:
On 2021-11-19 11:15, Paul Moore wrote:
> On Thu, Nov 4, 2021 at 5:53 PM Richard Guy Briggs <rgb(a)redhat.com> wrote:
> > On 2021-11-04 17:29, Paul Moore wrote:
> > > On Thu, Nov 4, 2021 at 5:00 PM Richard Guy Briggs <rgb(a)redhat.com>
wrote:
> > > >
> > > > AUDIT_TIME_* events are generated when there are syscall rules
present that are
> > > > not related to time keeping. This will produce noisy log entries
that could
> > > > flood the logs and hide events we really care about.
> > > >
> > > > Rather than immediately produce the AUDIT_TIME_* records, store the
data and
> > > > log it at syscall exit time respecting the filter rules.
> > > >
> > > > Please see
https://bugzilla.redhat.com/show_bug.cgi?id=1991919
> > >
> > > Unfortunately that URL isn't publicly accessible. It might be
helpful
> > > to simply add the relevant information to the commit description[1]
> > > and omit the link entirely. Since this is just an RFC, please don't
> > > resend the patch just to include that information, you can simply
> > > reply to this thread with the additional info.
> >
> > Hmmm, sorry about that. There isn't really anything in that bz that
> > shouldn't be public, but I'll check before openning it up...
> >
> > Basically it was a report that:
> > TIME_ADJNTPVAL audit events are not generated if there are no syscalls
> > rules, but that these events are generated when at least one unrelated
> > syscall rule is added.
> >
> > This behaviour was confirmed but the conclusion about what should be the
> > correct behaviour differed from that of the reporter.
>
> I'm still wondering about the best way to handle this situation, and I
> want to make sure I'm understanding the problem correctly. So I'm
> clear on the problem, is the issue that the AUDIT_TIME records are
> being generated whenever at least one syscall filter is present,
> regardless of if that syscall is time related? With the expected
> behavior being that AUDIT_TIME records are only generated when a time
> related syscall is being audited?
Exactly.
In that case it seems pretty similar to the PATH record and I would
think that handling it in a similar manner would be The Right Thing to
do ... which looks like what you are doing.
You mentioned that you wanted to do some more work on this patch so
I'll hold off further comments until the updated patch is posted.
--
paul moore