RE: audit 0.6 release

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