close(2) not being audited?
Steve Grubb
sgrubb at redhat.com
Sat Dec 30 14:36:05 UTC 2006
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
More information about the Linux-audit
mailing list