audit 1.5.6 released

Hi,

I've just released a new version of the audit daemon. It can be downloaded from http://people.redhat.com/sgrubb/audit It will also be in rawhide soon. The Changelog is:

- Fix potential buffer overflow in print clone flags of auparse
- Add new App Armor types (John Johansen)
- Adjust Menu Location for system-config-audit (Miloslav Trmac)
- Fix python traceback parsing watches without perm statement (Miloslav Trmac)
- Added databuf_strcat function to auparse (John Dennis)
- Update auditctl to handle legacy kernels when putting a watch on a dir
- Fix invalid free and memory leak on reload in auditd (Miloslav Trmac)
- Fix clone flags in auparse (John Ramsdell)
- Add interpretation for F_SETFL of fcntl (John Ramsdell)
- Fix acct interpretation in auparse
- Makefile cleanups (John Ramsdell)

This is nothing but a bugfix release. Anyone using 1.5.5 is advised to upgrade.

Please note that the audit event dispatcher will be changing again in the next release. This is the current area of work and this one is considered temporary. This release is primarily to get some other needed fixes out for people to use. I should have a new release soon.

Please let me know if there are any problems with this release.

-Steve

Let me suggest that a library function be added to auparse that identifies the version of the library to its clients. This is helpful for generating good debugging messages, but also eases the task of associating a version number with the output of a log analysis program. Knowing the version number may be important as auparse/interpret.c may interpret more fields in the future, and analysis programs may be sensitive to the changes.

To apply, use -p2, not the usual -p1.

John

diff -urN a/audit-1.5.6/auparse/auparse.c b/audit-1.5.6/auparse/auparse.c
@@ -29,6 +29,12 @@
 #include <string.h>
 #include <unistd.h>
 
+/* provide version information for this library to clients */
+const char *
+auparse_version(void)
+{
+  return VERSION;
+}
 
 static int debug = 0;
 

diff -urN a/audit-1.5.6/auparse/auparse.h b/audit-1.5.6/auparse/auparse.h
@@ -89,6 +89,8 @@
 int auparse_get_field_int(auparse_state_t *au);
 const char *auparse_interpret_field(auparse_state_t *au);
 
+/* Identify library version */
+const char *auparse_version(void);
 
 #ifdef __cplusplus
 }

diff -urN a/audit-1.5.6/docs/auparse_version.3 b/audit-1.5.6/docs/auparse_version.3
@@ -0,0 +1,18 @@
+.TH "AUPARSE_VERSION" "3" "July 2007" "Red Hat" "Linux Audit API"
+.SH NAME
+auparse_version \- version number of library
+.SH "SYNOPSIS"
+.B #include <auparse.h>
+.sp
+const char *auparse_version (void);
+
+.SH "DESCRIPTION"
+
+auparse_version returns the version number of the library.
+
+.SH "RETURN VALUE"
+
+A string containing the version number.
+
+.SH AUTHOR
+John D. Ramsdell

diff -urN a/audit-1.5.6/docs/Makefile.am b/audit-1.5.6/docs/Makefile.am
@@ -43,5 +43,5 @@
 auparse_next_field.3 auparse_next_record.3 auparse_reset.3 \
 auparse_timestamp_compare.3 aureport.8 ausearch.8 ausearch_add_item.3 \
 ausearch_clear.3 ausearch_next_event.3 ausearch_set_stop.3 autrace.8 \
-get_auditfail_action.3 set_aumessage_mode.3
+get_auditfail_action.3 set_aumessage_mode.3 auparse_version.3
 

diff -urN a/audit-1.5.6/docs/Makefile.in b/audit-1.5.6/docs/Makefile.in
@@ -214,7 +214,7 @@
 auparse_next_field.3 auparse_next_record.3 auparse_reset.3 \
 auparse_timestamp_compare.3 aureport.8 ausearch.8 ausearch_add_item.3 \
 ausearch_clear.3 ausearch_next_event.3 ausearch_set_stop.3 autrace.8 \
-get_auditfail_action.3 set_aumessage_mode.3
+get_auditfail_action.3 set_aumessage_mode.3 auparse_version.3
 
 all: all-am
 

Thank you Steve. With this update, and bug fixes to my code, my analysis program completes without reporting internal inconsistencies. This usually means most of the bugs have been removed.

I carefully studied the output of my analysis program, and found one particularly odd line of output. I traced it back to an interesting audit event in the raw log (syscall 5 is the open system call):

type=SYSCALL msg=audit(1185450758.059:1699): arch=40000003 syscall=5 success=yes exit=0 a0=bfb9ec10 a1=241 a2=1b6 a3=4284b560 items=2 ppid=1 pid=22079 auid=500 uid=500 gid=500 euid=500 suid=500 fsuid=500 egid=500 sgid=500 fsgid=500 tty=(none) comm="broadcast" exe="/home/ramsdell/scm/polgen/src/daemon-example/broadcast" subj=user_u:system_r:unconfined_t:s0 key=(null) type=CWD msg=audit(1185450758.059:1699): cwd="/"
type=PATH msg=audit(1185450758.059:1699): item=0 name="/tmp/" inode=4128769 dev=fd:00 mode=041777 ouid=0 ogid=0 rdev=00:00 obj=system_u:object_r:tmp_t:s0
type=PATH msg=audit(1185450758.059:1699): item=1 name="/tmp/polgen_daemon.txt" inode=4128817 dev=fd:00 mode=0100640 ouid=500 ogid=500 rdev=00:00 obj=user_u:object_r:tmp_t:s0

Notice this event has two PATH records, whereas all of the many other open events I studied in my logs have one PATH record. It's as if the open system call can behave as the openat system call. I changed my analysis program to use the last PATH record to find the file name, so that the same code can be used to analyze open and openat system calls.

John

But openat does give a different output:

type=PATH msg=audit(07/27/2007 10:42:17.954:153) : item=0 name=test inode=6131 dev=08:06 mode=file,sgid,451 ouid=root ogid=root rdev=00:00 obj=user_u:object_r:tmp_t:s0
type=CWD msg=audit(07/27/2007 10:42:17.954:153) : cwd=/root type=SYSCALL msg=audit(07/27/2007 10:42:17.954:153) : arch=i386 syscall=openat success=yes exit=4 a0=3 a1=80485d5 a2=42 a3=8048529 items=1 ppid=6310 pid=6312 auid=sgrubb uid=root gid=root euid=root suid=root fsuid=root egid=root sgid=root fsgid=root tty=pts0 comm=test exe=/home/sgrubb/test/openat/test subj=user_u:system_r:unconfined_t:s0 key=(null)

Now, the out put changes if I do not include <sys/stat.h> and do not define __USE_ATFILE ! When I compile the test program I get a warning: implicit declaration of function ‘openat’. Low and behold the record changes to this:

type=PATH msg=audit(07/27/2007 10:33:59.030:81) : item=1 name=test inode=6131 dev=08:06 mode=file,sgid,451 ouid=root ogid=root rdev=00:00 obj=user_u:object_r:tmp_t:s0
type=PATH msg=audit(07/27/2007 10:33:59.030:81) : item=0 name=/root inode=2 dev=08:06 mode=dir,sticky,777 ouid=root ogid=root rdev=00:00 obj=system_u:object_r:tmp_t:s0
type=CWD msg=audit(07/27/2007 10:33:59.030:81) : cwd=/root type=SYSCALL msg=audit(07/27/2007 10:33:59.030:81) : arch=i386 syscall=openat success=yes exit=4 a0=3 a1=80485d5 a2=42 a3=8048529 items=2 ppid=4148 pid=4150 auid=sgrubb uid=root gid=root euid=root suid=root fsuid=root egid=root sgid=root fsgid=root tty=pts0 comm=test exe=/home/sgrubb/test/openat/test subj=user_u:system_r:unconfined_t:s0 key=(null)

The call in both cases was this:

int main(void)

{
        int dir_fd, fd;
        DIR *d = opendir("/tmp");
        dir_fd = dirfd(d);
        fd = openat(dir_fd, "test", O_CREAT|O_RDWR);
        close (fd);
        closedir(d);

        return 0;
}

In neither record for openat did I get the "/tmp" directory which I thought I should get. I don't understand why it mutates between the two forms, nor do I get what I think I should. I suspect the *at functions should have the referenced directory recorded just as open records the cwd so paths can be reassembled. It seems like we need a AUDIT_DIR aux record for path recreation when something relative is used as in the example program.

Any kernel people want to chime in?

-Steve

I notice that /bin/rm no longer uses the unlink system call, but instead uses unlinkat.

...

Note that my trick of looking at the last path record for the file name works for both forms of openat events. It also works with unlink and unlinkat.

I guess I had better add programs that use openat to my test suite, so as to ensure the trick works.

John

I'm probably out of my league by responding here, but some syscall records do have more than one path. For instance,

mv file1 file2

will have a path record for both file1 and file2 ... The same type of thing is true for cp file1 file2

Karen Wieprecht

You are correct. I would expect the rename(2) system call to have two PATH records, and the renameat(4) call to have four. I suppose I should see what a renameat audit record looks like given Steve's interesting findings about openat.

John

I found the place in the source for the program that generates this system call. It is a call to freopen on stderr.

John