Re: close(2) not being audited?

[Steve Grubb <sgrubb@redhat.com>]

On Thursday 28 December 2006 16:58, Todd, Charles wrote:
> NISPOM 8-602 requires that CLOSE operations on security-relevant objects be
> logged.  Well, I've got logging for OPEN on security-relevant objects (with
> the watches) working VERY well (yeah!!!).  The default CAPP.rules file had
> nothing about close(2), 

CAPP says nothing about this syscall other than the ability to audit it. Which 
you can get with "auditctl -a entry,always -S close", which admittedly is 
overkill.

> so just to test it, I ran: 
>   auditctl -a entry,possible -S close
> and then as a normal user typed: cat /etc/group (which is a
> security-relevant object that I have permission to open, and thus
> eventually close)

I'd want to see the accompanying watch for that file.

> However, when I review the audit files, nothing is logged.  

Hmm.

> If I change the "entry,possible" to "entry,always" then lots of stuff gets
> logged, but not my actual opening of the /etc/group file.

This would log all close system calls - even socket closes.

>   There is only one other thing that could be a configuration issue:
> "auditctl -l |grep /etc/group" reveals an additional "perm=wa" field
> that is set by the -p option in CAPP.rules, but even if root writes to
> one of the watched files, close(2) is still not logged.

I think that open is called with either read and/or write flag set. This is 
how it picks up an event for open. However, close is neither read nor write.

> Do I have a configuration problem or is something deeper going on?

Probably something deeper. I'd say you should open a support request so that 
it gets fixed. 

I think we'd also want to verify this for the current upstream kernels to make 
sure kernel.org kernels havethis solved. FC6 is probably new enough to test 
for that purpose.

-Steve