From mboxrd@z Thu Jan 1 00:00:00 1970 From: LC Bruzenak Subject: Re: Logging failed open() calls on /var/log/audit/audit.log Date: Thu, 29 Jun 2006 13:04:38 -0500 Message-ID: <1151604278.4879.63.camel@fryspc> References: <20060627211553.GA11601@zk3.dec.com> <20060629163454.GA5188@w-m-p.com> Mime-Version: 1.0 Content-Type: text/plain Content-Transfer-Encoding: 7bit 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 k5TI53jt029694 for ; Thu, 29 Jun 2006 14:05:03 -0400 Received: from fryspc.bruzenak.com (rrcs-24-242-137-194.sw.biz.rr.com [24.242.137.194]) by mx3.redhat.com (8.13.1/8.13.1) with ESMTP id k5TI4sk7001525 for ; Thu, 29 Jun 2006 14:04:56 -0400 In-Reply-To: <20060629163454.GA5188@w-m-p.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: Klaus Weidner Cc: linux-audit@redhat.com List-Id: linux-audit@redhat.com On Thu, 2006-06-29 at 11:34 -0500, Klaus Weidner wrote: > 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 Klaus, What you are saying is true, however I would caution against allowing the traversal because I think my accreditors would argue that it would open a covert channel potential. Obviously there would need to be a participating high-side or privileged signaler, but at least in our case I believe we can live with the directory rejection rather than the file itself. In short, I agree with your interpretation. LCB. -- LC Bruzenak lenny@bruzenak.com