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

[Call, Tom H]

Lockheed Martin Proprietary/Export Controlled Information
Proprietary information owned by Lockheed Martin, such as business, financial or technical information, that requires protection from unauthorized disclosure, and is subject to US or foreign export control laws or regulations.

.
.
.
Message Start:
-----------------------
Steve,

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.
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
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://listman.redhat.com/archives/linux-audit/attachments/20110418/dd7590c1/attachment.htm>