Re: close(2) not being audited?
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