From mboxrd@z Thu Jan 1 00:00:00 1970 From: Klaus Weidner Subject: Re: Logging failed open() calls on /var/log/audit/audit.log Date: Thu, 29 Jun 2006 11:34:54 -0500 Message-ID: <20060629163454.GA5188@w-m-p.com> References: <20060627211553.GA11601@zk3.dec.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Return-path: Received: from mx1.redhat.com (mx1.redhat.com [172.16.48.31]) by int-mx1.corp.redhat.com (8.12.11.20060308/8.12.11) with ESMTP id k5TGZNIF007494 for ; Thu, 29 Jun 2006 12:35:23 -0400 Received: from mail.atsec.com (mail.atsec.com [195.30.252.105]) by mx1.redhat.com (8.12.11.20060308/8.12.11) with ESMTP id k5TGZKqx010701 for ; Thu, 29 Jun 2006 12:35:21 -0400 Content-Disposition: inline In-Reply-To: <20060627211553.GA11601@zk3.dec.com> 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 , linux-audit@redhat.com List-Id: linux-audit@redhat.com On Tue, Jun 27, 2006 at 05:15:53PM -0400, Amy Griffis wrote: > Robert Giles wrote: [Tue Jun 27 2006, 04:43:10PM EDT] > > 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. CAPP etc. require audit records for unsuccessful attempts to access objects, but we've generally used the interpretation that there is no access attempt to the object if a containing directory already rejects the directory traversal before getting to the object. It's not ideal but it's the best fit to the way the path access works. If you really insist on the audit records, you could weaken the restrictions on the /var/log/audit/ directory (for example 711 permissions) so that it doesn't reject the traversal. The audit files are still protected of course. -Klaus