public inbox for linux-audit@redhat.com
 help / color / mirror / Atom feed
From: Steve Grubb <sgrubb@redhat.com>
To: linux-audit@redhat.com
Subject: Re: [PATCH] auparse.c events_are_equal() and event matching
Date: Mon, 01 Dec 2014 09:58:54 -0500	[thread overview]
Message-ID: <6416589.0lGf8CPosh@x2> (raw)
In-Reply-To: <5474043E.4010407@mozilla.com>

On Monday, November 24, 2014 08:23:26 PM Guillaume Destuynder wrote:
> on our RHEL6 machines, with kernel 2.6.32, we noticed that sometimes an
> audit message comes in but libaudit does not see it as the same event.
> 
> The milliseconds field of the timestamp differs (but the timestamp
> seconds and event serial are identical).

This seems to be a bug in the kernel code. Its a fundamental principle that 
all records that make up an event have the same time stamp and serial number. 
My guess (not having looked at the code) is that its calling a convenience 
function that looks up the time anew for each record rather than reading it 
once and reusing it as it outputs each record of the event.

The code in audit_log_exit is probably the only place where it really matters 
because it can generate multiple records composing 1 event. We might need a 
audit_log_start_time() function that takes the timestamp as a parameter. The 
old audit_log_start can grab a new timestamp and call the new function with 
the timestamp.

I think we should fix the source of the problem. This is a really good finding. 
I didn't realize this was happening.

Thanks,
-Steve

> The check to determine if 2 messages are part of the same event is done
> by events_are_equal() in auparse/auparse.c (audit userspace library).
> 
> There is a comment that indicate that this is voluntary - however, I
> could not find why. I suspect this is for searches over long periods of
> time when the serial may roll over.
> 
> In case this was simply overlooked I'm attaching a patch that fixes it
> for us. It keeps the timestamp check for the seconds, which works fine
> and would still work with serial rolling over.
> 
> Again- its relatively rare in our logs that the timestamp's millisecond
> field differs and we log very heavily - so it's not that easy to reproduce.

  reply	other threads:[~2014-12-01 14:58 UTC|newest]

Thread overview: 7+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2014-11-25  4:23 [PATCH] auparse.c events_are_equal() and event matching Guillaume Destuynder
2014-12-01 14:58 ` Steve Grubb [this message]
2014-12-02  2:51   ` Richard Guy Briggs
2014-12-02 13:44     ` Steve Grubb
2014-12-10  2:54 ` Richard Guy Briggs
2014-12-11  0:12   ` Guillaume Destuynder
2014-12-11 19:34     ` 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=6416589.0lGf8CPosh@x2 \
    --to=sgrubb@redhat.com \
    --cc=linux-audit@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