All of lore.kernel.org
 help / color / mirror / Atom feed
From: Steve Grubb <sgrubb@redhat.com>
To: linux-audit@redhat.com
Subject: Re: Weird timestamp length constraint in auparse.c
Date: Mon, 14 Dec 2015 16:02:23 -0500	[thread overview]
Message-ID: <3542651.21VHabrmFL@x2> (raw)
In-Reply-To: <CAKC2Jd6sbeHdMBC_TT314NZ1TFe6QMtShXp=dQLCPb3KPiYCNA@mail.gmail.com>

Hello,

On Wednesday, December 09, 2015 06:10:08 PM Santosh Ananthakrishnan wrote:
> auparse breaks if supplied events with timestamps that are less than 10
> characters long, including the milliseconds field. This should never happen
> in production, but it can make for fairly mysterious output during testing
> if you're generating your own timestamp and eventid numbers :-)
> 
> I think the issue is in the str2event function:
> 
> static int str2event(char *s, au_event_t *e)
> {
>         char *ptr;
>         errno = 0;
>         ptr = strchr(s*+10*, ':');
>         if (ptr) {
>                 e->serial = strtoul(ptr+1, NULL, 10);

Yes, this is intentional. Let's look at an event:

type=DAEMON_START msg=audit(1450095206.768:6444):

When str2event is entered, the pointer is at the '1'. The function calling it 
located the parenthesis.


> This function seems to be searching for the colon that splits the timestamp
> from the eventId, but it's starting at s+10, instead of just s. The
> variable s points to the first byte after the "msg=audit(" prefix. (10 also
> happens to be the length of that prefix, which is what made me suspicious
> this might not be micro-optimization)

It also turns out to be the length of the decimal number for time. The reason 
that we can "safely" do this is because the audit project started in 2004. 
There would not be any kernel prior to that which has audit events created by 
the current audit system. If you get the time_t representation for August 
2004, which is the time that the Linux audit mail list was started, you get: 
1091332800. Any time after that would be bigger and longer. When time_t maxes 
out it'll look like:

time_t: 0xFFFFFFFF, dec: 4294967295, date: Sun Feb  7 01:28:15 2106

Its still 10 digits long. So, the idea was to skip over the first 10 characters 
and start looking for the serial number closer to where its going to be in the 
buffer.

I suppose a quick check could be done to make sure we don't have malformed 
records. Is that what you were wanting to see done?

Thanks,
-Steve

  reply	other threads:[~2015-12-14 21:02 UTC|newest]

Thread overview: 3+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2015-12-10  2:10 Weird timestamp length constraint in auparse.c Santosh Ananthakrishnan
2015-12-14 21:02 ` Steve Grubb [this message]
2015-12-14 21:24   ` Santosh Ananthakrishnan

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=3542651.21VHabrmFL@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 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.