Re: Auditing failures for files in protected directories - Lockheed Martin Proprietary/Export Controlled Information

[Steve Grubb <sgrubb@redhat.com>]

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