audit 0.6 release

[Browder, Tom]

I appreciate all the helpful comments on my look at auditd.

To see what I can do now with audit 0.6, I tried one rule similar to
requirements I've mentioned, one failed attempt to trigger an auditd
response, and looked at the output to see the feasibility of filtering
the output:

Using audit-0.6, my single rule is (from /sbin/audtctl -l):

AUDIT_LIST: exit always uid=507 (0x1fb) syscall=unlink

The failed attempt to be logged was:

  % rm /etc/passwd

The two messages generated in audit.log were:

type=KERNEL msg=audit(1105106227.435:12373636): item=0 name=/etc/passwd
\
  inode=5079041 dev=00:00-l inode=3080372 dev=00:00loginuid=-1 \
  uid=507 gid=503 euid=507 suid=507 fsuid=507 egid=503 sgid=503
fsgid=50333gid=503
type=KERNEL msg=audit(1105106227.435:12373636): syscall=10
exit=4294967283 \
  a0=bff86b22 a1=0 a2=80505e4 a3=bff86b22 items=1 pid=6137 loginuid=-1 \
  uid=507 gid=503 euid=507 suid=507 fsuid=507 egid=503 sgid=503
fsgid=503503

Notice that I can get the file name, the system call, and the exit
status of
unlink (but I suspect the print format for the exit code is %u instead
of %d,
thus the apparent large number probably from a negative exit code).

But do there have to be two messages?  Having one would enable easy
querying
(assuming I can parse on exit != 0), otherwise a little more difficult
(can I assume the messages always come in matching, adjacent pairs?).

To sum up, I believe I can write a perl parser to do what I need now
(assuming the exit code is correct), even though the message traffic is
so high.  As autitd's rule capability gets more sophisticated, the
message traffic should decrease immensely.

I also will write a perl script to perform as my manual rule loader
until auditd has its own.

Thanks.

-Tom Browder