8:09 a.m.
I have a test suite that generates every system call analyzed by our
package. The suite runs several programs that do a variety of things,
including opening files. I traced the set of programs, and retrieved
the records using
ausearch -r -p P > P.txt
where P is the process ID of each traced program.
When I attempt to analyze the logs, my program blows up because it
assumes that every syscall audit event for the open syscall will
include a PATH record. I made a quick edit of the analysis program,
and discovered that 24 open syscall records have no PATH record, and
sometimes the CWD record is missing too.
$ python auditopen.py -i ../autsv/*.txt
Of 421 events with a SYSCALL record with syscall=open
401 have CWD
397 have PATH
0 have CWD but no PATH
$
Is it appropriate for audit analysis programs to assume a PATH record
will be available with every open syscall event? I cannot see how to
do my analysis without the PATH record.
8:51 a.m.
On Monday 23 July 2007 09:09:22 John D. Ramsdell wrote:
Is it appropriate for audit analysis programs to assume a PATH
record
will be available with every open syscall event? I cannot see how to
do my analysis without the PATH record.
There should be a PATH record for every open. Have you verified the logs or
trusting ausearch? (Trying to figure out if there is a kernel problem or
search problem.) As a first step, I'd construct some kind of regex command to
see if you can verify that the kernel is recording PATH records for all
opens. You may need to narrow the test case so that there aren't as many
records to dig through.
-Steve
9:07 a.m.
Steve Grubb <sgrubb(a)redhat.com> writes:
There should be a PATH record for every open.
Okay, I'll direct my search as you suggested. I'll delete the current
audit log, restart my daemon, run the test suite, and then compare the
raw log with what one gets from ausearch. I'll modify my python
program to print the timestamp of an open event without a path, easing
the task of finding the record in the raw data. Alas, the part of my
day free of meetings is at an end, but I'll get on this soon.
John
PS. The output of my program should have said:
$ python auditopen.py -i ../autsv/*.txt
Of 421 events with a SYSCALL record with syscall=open
401 have CWD
397 have PATH
0 have PATH but no CWN
$
The last line in the original message erroneously said:
0 have CWD but no PATH
1:47 p.m.
Steve Grubb <sgrubb(a)redhat.com> writes:
There should be a PATH record for every open. Have you verified the
logs or trusting ausearch?
The short version of what I found is that the missing PATH records
always appear in the raw logs, but both ausearch and auparse fail to
return some PATH records with their associated SYSCALL record. A PATH
record gets ignored when another syscall event record occurs between
the SYSCALL record and the PATH record.
I'll send you a long version of my results off line as the data to
support the report is voluminous.
John
2 p.m.
On Monday 23 July 2007 14:47:33 John D. Ramsdell wrote:
A PATH record gets ignored when another syscall event record occurs
between
the SYSCALL record and the PATH record.
OK good. That is a known problem (bz 235398) that should be worked on right
after we get the improved dispatcher finished.
-Steve
2:41 p.m.
Steve Grubb <sgrubb(a)redhat.com> writes:
OK good. That is a known problem (bz 235398) that should be worked
on right after we get the improved dispatcher finished.
Hmm. I'm wedged if I cannot process open system call records. I bet
I can quickly write some script that interchanges adjacent audit
records that are out of order in the raw logs, so as to allow me to
proceed. If someone else has a record sorter, please send it along.
John
2:56 p.m.
On Monday 23 July 2007 15:41:31 John D. Ramsdell wrote:
I bet
I can quickly write some script that interchanges adjacent audit
records that are out of order in the raw logs, so as to allow me to
proceed. If someone else has a record sorter, please send it along.
setroubleshoot is written in python and it sorts its input stream to solve
this in the mean time. You might look there for some example code.
-Steve
7:06 a.m.
Steve Grubb <sgrubb(a)redhat.com> writes:
setroubleshoot is written in python and it sorts its input stream to
solve
this in the mean time. You might look there for some example code.
I was unable to find the relevant code with a quick look, but I didn't
take much time as I knew a short script would to do the trick. I just
sorted on the serial numbers in the audit message. Diff'ing showed
quite a bit of motion in the sorted output. Also, I notice that in
just one message, the msg field value does not end with a colon:
type=DAEMON_START msg=audit(1185203485.586:824) auditd start, ver=1.5.5, format=raw,
auid=500 pid=24638 res=success, auditd pid=24638
John
#! /bin/sh
python -E -c '
import sys, re
def main():
pattern = re.compile("\smsg=audit\(\d+\.\d+:(\d+)\):?\s")
for line in sys.stdin:
match = pattern.search(line)
if not match:
sys.stderr.write("cannot parse audit message:
'\''%s'\''\n" % line)
sys.exit(1)
sys.stdout.write(match.group(1) + "\t" + line)
if __name__ == "__main__":
main()
' | sort -n -s -k 1 | cut -f 2-
4:30 p.m.
On Tuesday 24 July 2007 08:06:44 am John D. Ramsdell wrote:
Also, I notice that in
just one message, the msg field value does not end with a colon:
type=DAEMON_START msg=audit(1185203485.586:824) auditd start, ver=1.5.5,
format=raw, auid=500 pid=24638 res=success, auditd pid=24638
Actually, it looks like all the DAEMON_ records are missing a ':' after the
timestamp. The parsers are not exactly looking for it, but I'll add it for
consistency.
-Steve
6360
days inactive
6361
days old
linux-audit@lists.linux-audit.osci.io
8 comments
2 participants
participants (2)
-
John D. Ramsdell -
Steve Grubb