From: Paul Moore <paul@paul-moore.com>
To: Richard Guy Briggs <rgb@redhat.com>
Cc: Eric Paris <eparis@parisplace.org>,
Linux-Audit Mailing List <linux-audit@redhat.com>
Subject: Re: [RFC PATCH v1] audit: log AUDIT_TIME_* records only from rules
Date: Fri, 19 Nov 2021 11:15:55 -0500 [thread overview]
Message-ID: <CAHC9VhRzr=0_ZQE47RTYvNqQHezkNgry_p08NAHSmixMVxGh7Q@mail.gmail.com> (raw)
In-Reply-To: <20211104215313.GJ1550715@madcap2.tricolour.ca>
On Thu, Nov 4, 2021 at 5:53 PM Richard Guy Briggs <rgb@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@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?
--
paul moore
www.paul-moore.com
--
Linux-audit mailing list
Linux-audit@redhat.com
https://listman.redhat.com/mailman/listinfo/linux-audit
next prev parent reply other threads:[~2021-11-19 16:16 UTC|newest]
Thread overview: 14+ messages / expand[flat|nested] mbox.gz Atom feed top
2021-11-04 20:59 [RFC PATCH v1] audit: log AUDIT_TIME_* records only from rules Richard Guy Briggs
2021-11-04 21:29 ` Paul Moore
2021-11-04 21:53 ` Richard Guy Briggs
2021-11-19 16:15 ` Paul Moore [this message]
2021-11-19 18:01 ` Richard Guy Briggs
2021-11-24 15:44 ` Paul Moore
2021-12-21 20:50 ` Richard Guy Briggs
2021-12-23 17:38 ` Paul Moore
2021-12-24 14:21 ` Richard Guy Briggs
2021-12-27 15:07 ` Paul Moore
2021-12-29 22:51 ` Paul Moore
2022-01-12 21:06 ` Richard Guy Briggs
2022-01-12 21:46 ` Casey Schaufler
2022-01-20 23:07 ` Paul Moore
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to='CAHC9VhRzr=0_ZQE47RTYvNqQHezkNgry_p08NAHSmixMVxGh7Q@mail.gmail.com' \
--to=paul@paul-moore.com \
--cc=eparis@parisplace.org \
--cc=linux-audit@redhat.com \
--cc=rgb@redhat.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).