Logging failed open() calls on /var/log/audit/audit.log
Amy Griffis
amy.griffis at hp.com
Tue Jun 27 21:15:53 UTC 2006
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
More information about the Linux-audit
mailing list