Dispatcher - single line output (perl)

[Leigh Purdie]

> > * Be chronologically distributed in some cases (event lines may be
> > spread over several seconds),
>
> Doubtful.

Excellent - thanks for that. I thought I spotted this issue very early
on in development, but can't find the problem now. That makes it much
easier if I'm going to rely on timeouts to push events out - I can
reduce the threshold from 10 seconds to closer to a second.

> > * Be out of sequence (numerically - two lines from event A, might be
> > followed by 1 line from event B, then another line from event A,
> > followed by the rest of event B).
>
> I haven't seen this except when we introduced a bug in the kernel.

Here's a sequence from the current auditd on RHEL4 U3:

type=PATH msg=audit(1146852361.936:228389): name="/etc/ld.so.cache"
flags=101  inode=32717 dev=fd:00 mode=0100644 ouid=0 ogid=0 rdev=00:00
type=SYSCALL msg=audit(1146852361.936:228390): arch=40000003 syscall=5
success=yes exit=3 a0=b7fbc918 a1=0 a2=0 a3=b7c4f8 items=1 pid=28998
auid=0 uid=0 gid=0 euid=0 suid=0 fsuid=0 egid=0 sgid=0 fsgid=0
comm="cat" exe="/bin/cat"
type=CWD msg=audit(1146852361.936:228390):  cwd="/"
type=PATH msg=audit(1146852361.936:228390): name="/lib/tls/libc.so.6"
flags=101  inode=148688 dev=fd:00 mode=0100755 ouid=0 ogid=0
rdev=00:00
type=CWD msg=audit(1146852361.931:228387):  cwd="/"
type=PATH msg=audit(1146852361.931:228387):
name="/lib/libselinux.so.1" flags=101  inode=148695 dev=fd:00
mode=0100755 ouid=0 ogid=0 rdev=00:00
type=SYSCALL msg=audit(1146852361.937:228391): arch=40000003 syscall=5
success=yes exit=3 a0=b7f11918 a1=0 a2=b7f08000 a3=b7c4f8 items=1
pid=28997 auid=0 uid=0 gid=0 euid=0 suid=0 fsuid=0 egid=0 sgid=0
fsgid=0 comm="init" exe="/sbin/init"
type=CWD msg=audit(1146852361.937:228391):  cwd="/"

Note the 228389, 228390, 228390, 228387, 228387, 228391, 228391 sequence.

Here's a quick method to identify them, based on eventnumber:
cat audit.log | awk '{print $2}' | cut -d: -f2 | sed 's/)//' | perl -e
'while($i=<STDIN>){chomp($i); if($i<$c){print "Reversal! (expected $c
or more, got $i)\n";} $c=$i; }'

Reversal! (expected 228390 or more, got 228387)
Reversal! (expected 228898 or more, got 228896)
Reversal! (expected 231981 or more, got 231973)
Reversal! (expected 232595 or more, got 232582)
Reversal! (expected 232610 or more, got 232604)
Reversal! (expected 232623 or more, got 232610)
Reversal! (expected 232713 or more, got 232689)
Reversal! (expected 232723 or more, got 232718)
...

> > However, the dispatcher infrastructure offers the potential to
> > implement this sort of functionality in user-space.
>
> Yes, I'm glad to see more people use this feature. Please note that there is
> an API version number that dictates the format of the records passed through
> the event dispatcher mechanism. Right now, the version is 0. It is the 1st 32
> bit word sent in the dispatcher header. I should probably add a specification
> to my people page so that everyone knows the rules.

It would actually be very helpful, if the dispatcher could receive
normal, newline/null terminated strings, rather than having to
interpret C structures (with the record type expanded as ASCII text).

Working with C structures in languages that are suited to text
processing (perl, python, php, etc), is challenging at best, and it's
these sort of languages that are most likely to do post-processing of
audit log data.

Any thoughts on this?

> Also, the audit daemon can be told not to log anything locally so that its all
> done across the network. Its in the auditd.conf man page. The dispatcher is
> responsible for adding the machine or host's name if that's needed in the
> record.

Yep. That's the ultimate goal. During the testing process, I'll just
avoid auditing write()s and related calls for the moment.

> We also getpwname/getgrname (with an internal cache to avoid recursive
> > audit events), and an internal simple realpath() to turn
> > /path/to/blah/../../to/somewhere into /path/to/somewhere.
>
> Not looking at your code...but you probably are referring to munging CWD &
> PATH records to create complete path? If not, that's what you need to do.

Yes. However, can the dispatcher guarantee that the paths in CWD and
PATH are fully resolved? (ie: we'll never see a
"/tmp/.././etc/./passwd" in PATH ?)

Regards,

Leigh.