From mboxrd@z Thu Jan 1 00:00:00 1970 From: Amy Griffis Subject: Re: Bypassing audit's file watches Date: Fri, 7 Jul 2006 22:00:02 -0400 Message-ID: <20060708020002.GA5350@dill.zko.hp.com> References: <44AE76A2.9050205@ornl.gov> Mime-Version: 1.0 Content-Type: text/plain; charset=utf-8 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 k6820V8k029758 for ; Fri, 7 Jul 2006 22:00:31 -0400 Received: from atlrel8.hp.com (atlrel8.hp.com [156.153.255.206]) by mx3.redhat.com (8.13.1/8.13.1) with ESMTP id k6820KL2010264 for ; Fri, 7 Jul 2006 22:00:25 -0400 Content-Disposition: inline In-Reply-To: <44AE76A2.9050205@ornl.gov> List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: linux-audit-bounces@redhat.com Errors-To: linux-audit-bounces@redhat.com To: Steve Cc: linux-audit@redhat.com List-Id: linux-audit@redhat.com Steve wrote: [Fri Jul 07 2006, 10:58:42AM EDT] > I have found that I can modify files that are being watched and audit > not catch it (ie. no events are dispatched). When monitoring a file for > all system calls, I can: > > echo "" > /file/to/watch > > or > > cat some_file > /file/to/watch > > without generating audit events. Are you seeing the open and not the write, or no records at all? With the current implementation, you should expect to see an event for open(). You wouldn't see a record for the write(), as the argument is an fd instead of a filename. As Tim mentioned, the idea is that to determine if a file is modified, you would filter for open() calls with either the O_RDWR or O_WRONLY flag. This is pretty unwieldy with the current feature set since you would need a separate rule for every possible combination of flags that includes O_RDWR or O_WRONLY. I really think we need to enhance the filtering options available for open() calls, since trying to audit the actual modifications is much more difficult. If you are missing events for open() calls, please let us know since that would be a bug (versus a lacking feature). Thanks for testing. Amy