audit 1.5.6 released

audit 1.5.6 released

[Steve Grubb]

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

[PATCH] Add auparse_version

[John D. Ramsdell]

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
--- a/audit-1.5.6/auparse/auparse.c	2007-06-18 16:48:53.000000000 -0400
+++ b/audit-1.5.6/auparse/auparse.c	2007-07-27 08:00:58.000000000 -0400
@@ -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
--- a/audit-1.5.6/auparse/auparse.h	2007-05-30 16:37:40.000000000 -0400
+++ b/audit-1.5.6/auparse/auparse.h	2007-07-27 07:53:33.000000000 -0400
@@ -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
--- a/audit-1.5.6/docs/auparse_version.3	1969-12-31 19:00:00.000000000 -0500
+++ b/audit-1.5.6/docs/auparse_version.3	2007-07-27 07:58:42.000000000 -0400
@@ -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
--- a/audit-1.5.6/docs/Makefile.am	2007-05-30 16:37:40.000000000 -0400
+++ b/audit-1.5.6/docs/Makefile.am	2007-07-27 07:55:57.000000000 -0400
@@ -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
--- a/audit-1.5.6/docs/Makefile.in	2007-07-27 07:28:33.000000000 -0400
+++ b/audit-1.5.6/docs/Makefile.in	2007-07-27 08:02:39.000000000 -0400
@@ -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
 

open record looks like openat

[John D. Ramsdell]

Steve Grubb <sgrubb@redhat.com> writes:

> I've just released a new version of the audit daemon. 

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

Re: open record looks like openat

[Steve Grubb]

On Friday 27 July 2007 10:10:17 John D. Ramsdell wrote:
> 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.

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

Re: open record looks like openat

[John D. Ramsdell]

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

Steve Grubb <sgrubb@redhat.com> writes:

> But openat does give a different output:

...

> Low and behold the record changes to this:

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

RE: open record looks like openat

[Wieprecht, Karen M.]

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   

Re: open record looks like openat

[John D. Ramsdell]

"Wieprecht, Karen M." <Karen.Wieprecht@jhuapl.edu> writes:

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

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

Re: open record looks like openat

[John D. Ramsdell]

ramsdell@mitre.org (John D. Ramsdell) writes:

> 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):

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

John