Hi Robert,
Robert Giles wrote: [Tue Jun 27 2006, 04:43:10PM EDT]
Howdy folks - I'm running audit-1.2.2 with the latest
audit-current git
tree (lspp.b20)...
The filesystem auditing seems to be working fine for all files *except*
the audit.log file.
For example, I do this:
auditctl -w /etc/shadow
auditctl -w /var/log/audit/audit.log
The audit daemon generates audit events for both successful and failed
open() calls to /etc/shadow, but only records *successful* accesses to
/var/log/audit/audit.log.
So if I attempt to access /etc/shadow as a regular user, a "success=no"
audit event is generated to indicate read failure - but if a regular user
attempts to read /var/log/audit/audit.log, nothing happens (no audit event
whatsoever is created).
This is because the regular doesn't have permissions to read
/var/log/audit. Since the path didn't fully resolve to
/var/log/audit/audit.log, the user didn't actually fail to access
audit.log, they failed to access /var/log/audit.
If you would like to see a record in this case, you must add a watch
for /var/log/audit.
*Successful* reads of /var/log/audit/audit.log (ie: as super-user) do
indeed generate the appropriate audit event in audit.log ("success=yes").
Is this the way the audit daemon is supposed to work? (some kind of race
condition if the audit daemon fully audits its own audit trail?)
(this question may seem unusual, but we're trying to audit "unsuccessful
attempts to access security-relevant objects"... the audit trail itself
constitutes a "security-relevant object").
Thanks again!
Hope this helps.
Amy