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
next prev parent 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.