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

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

[Call, Tom H]

[-- Attachment #1.1: Type: text/plain, Size: 1894 bytes --]

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

[-- Attachment #1.2: Type: text/html, Size: 31535 bytes --]

[-- Attachment #2: Type: text/plain, Size: 0 bytes --]

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

[Steve Grubb]

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