audit 0.9.9 released
by Steve Grubb
Hello,
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
tomorrow. The Changelog is:
- Fix user messages for people with older kernels
- Added support for FS_INODE and USYS_CONFIG records
- More cleanup of user space message functions
This is a bug fix release. Let me know if there are any problems.
-Steve
19 years, 6 months
audit.59 kernel
by David Woodhouse
Uploading now, patch attached.
* Fri Jun 17 2005 David Woodhouse <dwmw2(a)redhat.com> audit.59
- Add filters for user messages and watches
* Fri Jun 17 2005 David Woodhouse <dwmw2(a)redhat.com> audit.58
- Fix auditfs error handling, memory leak, watch removal (Tim)
--
dwmw2
19 years, 6 months
[PATCH] cleanups + fixes against audit.56
by Timothy R. Chavez
Hello,
This patch introduces fixes for:
1. sys_rename() return code debacle
->
as a side effect of removing the error handling from fs/namei.c this bug was
also removed
2. leaky memory in auditfs_attach_wdata in failure path
3. NULL dereference on audit_inode_free()
->
race could occur between the child inode being deleted and the watch being
removed from parent
This patch adds:
1. Implicit watc removal message with -1 loginuid
2. New type, AUDIT_FS_INODE (1308)
->
now that we have watches per inode per record, we collect common inode
information for the watch on AUDIT_FS_INODE and use AUDIT_FS_WATCH to list
the watch information
3. Minor code cleanups (eliminating pointless goto's)
What's left:
1. Hooking chmod/chown/chgrp and the appropriate ACL calls (Me)
2. Watch scalability problem (Me)
3. AUID filtering on USER messages and watches (David)
4. PATH record woes... add a new token stating "I'm the parent of the file or
I'm the file"
-tim
19 years, 6 months
audit 0.9.7 released
by Steve Grubb
Hello,
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
tomorrow. The Changelog is:
- fixed bug in send_user_message which errored on pam logins
- Change nanosleeps over to select loops
- Change the 'e' option to auditctl -p to 'x'
This release is prompted by a problem that may cause pam to not let you in
when xscreensaver starts running. This release also has noticeable speed
improvements. The culprit was nanosleep. I removed it everywhere and replaced
it with select and the whole thing runs much faster.
Also, as Tim requested, the 'e' option to auditctl -p was changed to 'x'.
Please update your scripts.
-Steve
19 years, 6 months
'e' to 'x' in auditctl -p
by Timothy R. Chavez
Hello,
Let's change the 'e' to an 'x' in for the -p field...no one likes 'e' for execute :-(...
Steve, whadda think?
-tim
19 years, 6 months
audit-0.9.6 released
by Steve Grubb
Hello,
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
tomorrow. The Changelog is:
- fix bug in incremental flush where is wrongly reported an error
- ausearch should not do uid check for -if option
- adjust ipc interpretation to not use ipc.h
There's some documentation updates as well. Please let me know if there are
any problems.
-Steve
19 years, 6 months
Re: audit.log space requirements:
by Michael C Thompson
Last attempt, today isn't fairing well for me. I promise no more duplicate
messages.
Appologies for the double-send, but the first one is clearly incomplete,
somehow I managed to hit send.
To begin the space-requirements discussion:
A log file of 2133 lines, having been generated from running the system
call tests suite, is a size of 302539 bytes (300k if you will).
While this isn't truely indicitive of the size, and I'm sure Ken's
production environment will yeild more insightful results, this still gives
us a pretty good idea of size vs space requirements.
This ratio yields a value of approximately 141 bytes per line. The standard
SYSCALL log entry (which generates the SYSCALL, CWD & PATH records), is 483
bytes per syscall. So after about 2000 syscalls, your log is already a meg.
Of course, that doesn't include audit start/stop and rule additions, but I
think it would be safe to assume those aren't going to happen with any sort
of frequency that it will cause a significant impact.
Mike
19 years, 6 months
encountering problems with PATH_MAX testing
by Loulwa Salem
I am writing the error cases for testing the PATH_MAX variables in auditctl.
My general test case structure is as follows:
1- create directory /tmp/dirname_4085_long (using the syscall
mkdir(directory, mode))
2- attempt to add watch on /tmp/dirname_4085_long/files_ok_length
(I am changing length of the file (within its NAME_MAX limit to make
total strlen() add up to what I am testing for (>PATH_MAX, =PATH_MAX,
=PATH_MAX+1, and =PATH_MAX-1 )
Problem:
trying to create the directory in step 1 above fails (with errno 36
(ENAMETOOLONG)). Therefore I can't even add a watch on the file using
that path (since the parent directory dirname_4085_long does not exist).
In the fail cases (>PATH_MAX, and =PATH_MAX+1) auditctl catches the
length issue first (so don't care much about the errno), and returns
correct return code. However, in the cases where I am supposed to pass
the auditctl (=PATH_MAX, and =PATH_MAX-1) and get to insert a watch, I
get caught in the mkdir syscall check.
auditctl is behaving correctly when it checks length of path, but it
still returns an error because it is caught when actually trying to
insert the watch and I get:
Error sending watch insert request (File name too long)
Error sending watch to kernel
Anybody can think of a way to go around this and still test the
=PATH_MAX, and =PATH_MAX-1 cases?
thanks,
- Loulwa
19 years, 6 months
audit 0.9.5 released
by Steve Grubb
Hello,
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
tomorrow. The Changelog is:
- interpret socketcall based on a0 in ausearch
- change call sequence to make user space messages faster
- update return val for auditctl
This is a bug fix release. Please let me know if there are any problems.
-Steve
19 years, 6 months
