All of lore.kernel.org
 help / color / mirror / Atom feed
From: Steve Grubb <sgrubb@redhat.com>
To: burn@swtf.dyndns.org, Paul Moore <paul@paul-moore.com>
Cc: Richard Guy Briggs <rgb@redhat.com>,
	Linux Audit <linux-audit@redhat.com>
Subject: Re: Occasional delayed output of events
Date: Tue, 19 Jan 2021 16:51:08 -0500	[thread overview]
Message-ID: <805552026.0ifERbkFSE@x2> (raw)
In-Reply-To: <CAHC9VhQzr94BdBY3voNEMxzBPM-KS3h1V=epCMMsknfu6Q5vag@mail.gmail.com>

On Tuesday, January 19, 2021 3:26:04 PM EST Paul Moore wrote:
> On Tue, Jan 19, 2021 at 2:38 PM Burn Alting <burn.alting@iinet.net.au> 
wrote:
> > All systems use chrony (current NTP daemon). One is a VM (on top of KVM)
> > and the other a bare metal deployment. Does the above explain my second
> > data set (in the issue) from a bare metal Centos 8 host? Perhaps Lenny's
> > comments bare investigation. Either way, I will offer a patch to the
> > user space code to, based on a configuration value, manage correctly
> > such activity.
> ...
> 
> > msg=audit(1609920994.483:1787848):
> > msg=audit(1609920994.483:1787848):
> > msg=audit(1609920994.483:1787848):
> > msg=audit(1609920994.483:1787848):
> > msg=audit(1609920994.483:1787848):
> > msg=audit(1609920994.484:1787849):
> > msg=audit(1609920994.484:1787849):
> > msg=audit(1609921000.636:1787850):
> > msg=audit(1609921000.636:1787850):
> > msg=audit(1609921000.636:1787850):
> > msg=audit(1609921008.456:1787851):
> > msg=audit(1609921008.456:1787851):
> > msg=audit(1609921008.456:1787851):
> > msg=audit(1609921008.456:1787851):
> > msg=audit(1609921008.456:1787851):
> > msg=audit(1609921008.456:1787851):
> > msg=audit(1609920994.484:1787849):
> > msg=audit(1609920994.484:1787849):
> > msg=audit(1609920994.484:1787849):
> > msg=audit(1609921010.837:1787852):
> > msg=audit(1609921010.837:1787852):
> > msg=audit(1609921010.837:1787852):
> 
> > msg=audit(1609921010.837:1787852):
> Looking at the extracted snippet above where event 1787849 is out of
> 
> order we see the following timestamps:
> > msg=audit(1609920994.483:1787848):
> > msg=audit(1609920994.484:1787849):
> > msg=audit(1609921000.636:1787850):
> > msg=audit(1609921008.456:1787851):
> 
> > msg=audit(1609921010.837:1787852):
>
> ... which looks correct in as much that the time doesn't appear to go
> backwards between events.  As I said before, I'm not sure how Steve's
> userspace works so the time may be a red herring.

It only handles one record at a time. No chance to mix things up.

The github issue says that 30-stig.rules is being used. If the system time 
changed with chrony, I would expect syscall events with adjtimex. But the 
only ones given are execve.

-Steve

> Barring some weird condition where auditd disconnects and quickly
> reconnects to the kernel, and/or dies and is replaced quickly, I'm not
> seeing anything obvious in the kernel which would cause this.  I'm not
> saying there isn't anything there, just that it isn't obvious to me at
> the moment :)




--
Linux-audit mailing list
Linux-audit@redhat.com
https://www.redhat.com/mailman/listinfo/linux-audit


  reply	other threads:[~2021-01-19 21:53 UTC|newest]

Thread overview: 32+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2021-01-01 21:22 Occasional delayed output of events Burn Alting
2021-01-03 15:41 ` Steve Grubb
2021-01-04  7:55   ` Burn Alting
2021-01-04 14:46     ` Steve Grubb
2021-01-04 20:12       ` Burn Alting
2021-01-10  4:39         ` Burn Alting
2021-01-15 22:18           ` Burn Alting
2021-01-16  0:35             ` Richard Guy Briggs
2021-01-16  2:42               ` Burn Alting
2021-01-17 14:07                 ` Paul Moore
2021-01-17 21:12                   ` Steve Grubb
2021-01-18 13:54                     ` Paul Moore
2021-01-18 14:31                       ` Steve Grubb
2021-01-18 20:34                         ` Burn Alting
2021-01-18 20:36                         ` Paul Moore
2021-01-19  8:18                           ` Burn Alting
2021-01-19 15:31                             ` Lenny Bruzenak
2021-01-19 19:11                             ` Paul Moore
2021-01-19 19:38                               ` Burn Alting
2021-01-19 20:26                                 ` Paul Moore
2021-01-19 21:51                                   ` Steve Grubb [this message]
2021-01-20  6:38                                     ` Burn Alting
2021-01-20 22:50                                       ` Paul Moore
2021-01-23 22:55                                         ` Burn Alting
2021-01-25 23:53                                           ` Steve Grubb
2021-01-26  0:11                                             ` Burn Alting
2021-01-26  0:20                                               ` Steve Grubb
2021-01-26  0:29                                                 ` Burn Alting
2021-01-26 11:53                                                   ` Burn Alting
2021-01-26 20:42                                                     ` Steve Grubb
2021-01-27 12:12                                                       ` Burn Alting
2021-01-19 20:42                               ` Richard Guy Briggs

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=805552026.0ifERbkFSE@x2 \
    --to=sgrubb@redhat.com \
    --cc=burn@swtf.dyndns.org \
    --cc=linux-audit@redhat.com \
    --cc=paul@paul-moore.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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.