On Monday, April 18, 2011 02:09:02 PM Call, Tom H wrote:
Hi, we have what I think is a new but undesirable result trying to
audit
access failures on files in a NISPOM audit configuration. We are not
seeing audit events for the access failures if the file has a parent
directory in the path that blocks access.
This is by design. The problem is in path resolution if its blocked by a permission
check, then the path name was never fully resolved. Therefore an access attempt never
really occurred. This is because the path name does not exist as a string inside the
kernel. A watch is converted into the inode's number and that is what is watched. I
think it is possible to place a watch on the directory and then see the failed access
of that directory.
But I did manage to get a bug filed that should help this in the future:
https://bugzilla.redhat.com/show_bug.cgi?id=661402
-Steve
Example:
Directory Permission
/var 755
/var/test 755
/var/test/bin 700
/var/test/bin/file 740
If an unprivileged user attempts to change /var/test/bin/file there is no
audit event recorded, either for the file or the parent directory
/var/test/bin. Our theory is that the failure to open the /var/test/bin
directory causes the audit path to be broken, or something to the like,
please excuse my terminology faux pas. This is happening on the following
configuration:
- Kernel - 2.6.18-238.5.1.el5
- Auditd - 1.7.18-2.el5
We have tried the following auditd rules (among others), no change in
result:
- -w /var/test/bin/file -p rwxa
- -a exit,always -S open -F path=/var/test/bin/file -F success=0
- -a exit,always -S open -R dir=/var/test/ -F success=0
And, this is something New, we have been using watches to audit this file
for years with previous kernel and auditd versions, such as:
- Kernel - 2.6.9-100.ELsmp
- Auditd - 1.0.16-4.el4_8.1
On this system we get audit events for access failures using a simple file
watch.
Are we missing something obvious?
Thanks! For any help,
Tom Call, LMCO