3:21 p.m.
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
7:25 a.m.
New subject: [PATCH] Add auparse_version
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
9:10 a.m.
New subject: open record looks like openat
Steve Grubb <sgrubb(a)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
9:59 a.m.
New subject: open record looks like openat
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
10:15 a.m.
New subject: open record looks like openat
I notice that /bin/rm no longer uses the unlink system call, but
instead uses unlinkat.
Steve Grubb <sgrubb(a)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
12:41 p.m.
New subject: open record looks like openat
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
12:57 p.m.
New subject: open record looks like openat
"Wieprecht, Karen M." <Karen.Wieprecht(a)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
1:14 p.m.
New subject: open record looks like openat
ramsdell(a)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
6357
days inactive
6359
days old
linux-audit@lists.linux-audit.osci.io
7 comments
3 participants
participants (3)
-
John D. Ramsdell -
Steve Grubb -
Wieprecht, Karen M.