Re: Logging failed open() calls on /var/log/audit/audit.log

[Amy Griffis <amy.griffis@hp.com>]

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