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