Steve,

Hi, we have what I think is a new but undesirable re= sult trying to audit access failures on files in a NISPOM audit configurati= on.

We are not seeing audit events for t= he access failures if the file has a parent directory in the path that bloc= ks access.

Example:

Directory = ; &nbs= p; Permission

/var &n= bsp; &n= bsp; = ; &nbs= p; 755

/var/test &= nbsp; = ; &n= bsp; 755

/var/test/bin &nb= sp; = 700

/= var/test/bin/file 740

If an unprivileged user attempts to change /v= ar/test/bin/file there is no audit event recorded, either for the fi= le or the parent directory /var/test/bin.<= /o:p>

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= .

&nbs= p;This is happening on the following configuration:

- Kernel - 2.6.18-238.5.1.el5

- &= nbsp; 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 = 211;S open –F path=3D/var/test/bin/file &= #8211;F success=3D0

- = -a exit,always –S open –R dir=3D/var/test/ -F success=3D0

And, this is something New, we hav= e been using watches to audit this file for years with previous kernel and = auditd versions, such as:

<= ![if !supportLists]>- Kernel - 2.6.9-100.ELsmp

- &nb= sp; 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

= --Boundary_(ID_ugUKQq1yrkDkOlb081gswA)-- --===============7641401101709415891== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline --===============7641401101709415891==-- From mboxrd@z Thu Jan 1 00:00:00 1970 From: Steve Grubb Subject: Re: Auditing failures for files in protected directories - Lockheed Martin Proprietary/Export Controlled Information Date: Mon, 18 Apr 2011 14:29:21 -0400 Message-ID: <201104181429.21743.sgrubb@redhat.com> References: Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Return-path: In-Reply-To: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: linux-audit-bounces@redhat.com Errors-To: linux-audit-bounces@redhat.com To: "Call, Tom H" Cc: "Walker, Patrick B" , "linux-audit@redhat.com" List-Id: linux-audit@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