From mboxrd@z Thu Jan 1 00:00:00 1970 From: Amy Griffis Subject: Re: Logging failed open() calls on /var/log/audit/audit.log Date: Tue, 27 Jun 2006 17:15:53 -0400 Message-ID: <20060627211553.GA11601@zk3.dec.com> References: Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Return-path: Received: from mx3.redhat.com (mx3.redhat.com [172.16.48.32]) by int-mx1.corp.redhat.com (8.12.11.20060308/8.12.11) with ESMTP id k5RLG8uW003941 for ; Tue, 27 Jun 2006 17:16:08 -0400 Received: from palrel10.hp.com (palrel10.hp.com [156.153.255.245]) by mx3.redhat.com (8.13.1/8.13.1) with ESMTP id k5RLFxRe029931 for ; Tue, 27 Jun 2006 17:16:00 -0400 Content-Disposition: inline In-Reply-To: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: linux-audit-bounces@redhat.com Errors-To: linux-audit-bounces@redhat.com To: Robert Giles Cc: linux-audit@redhat.com List-Id: linux-audit@redhat.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