From mboxrd@z Thu Jan 1 00:00:00 1970 From: Michael C Thompson Subject: Re: Bypassing audit's file watches Date: Fri, 07 Jul 2006 11:20:43 -0500 Message-ID: <44AE89DB.9080102@us.ibm.com> References: <44AE76A2.9050205@ornl.gov> <1152287952.21687.0.camel@localhost.localdomain> <44AE8715.5040309@us.ibm.com> Mime-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1; format=flowed 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 k67GL0WC025861 for ; Fri, 7 Jul 2006 12:21:00 -0400 Received: from e36.co.us.ibm.com (e36.co.us.ibm.com [32.97.110.154]) by mx3.redhat.com (8.13.1/8.13.1) with ESMTP id k67GKsFg000980 for ; Fri, 7 Jul 2006 12:20:54 -0400 Received: from westrelay02.boulder.ibm.com (westrelay02.boulder.ibm.com [9.17.195.11]) by e36.co.us.ibm.com (8.12.11.20060308/8.12.11) with ESMTP id k67GKmB6003535 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL) for ; Fri, 7 Jul 2006 12:20:49 -0400 Received: from d03av04.boulder.ibm.com (d03av04.boulder.ibm.com [9.17.195.170]) by westrelay02.boulder.ibm.com (8.13.6/NCO/VER7.0) with ESMTP id k67GK1Bk299900 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for ; Fri, 7 Jul 2006 10:20:03 -0600 Received: from d03av04.boulder.ibm.com (loopback [127.0.0.1]) by d03av04.boulder.ibm.com (8.12.11.20060308/8.13.3) with ESMTP id k67GKk6A029120 for ; Fri, 7 Jul 2006 10:20:46 -0600 In-Reply-To: <44AE8715.5040309@us.ibm.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: Michael C Thompson Cc: linux-audit@redhat.com List-Id: linux-audit@redhat.com Michael C Thompson wrote: > Timothy R. Chavez wrote: >> On Fri, 2006-07-07 at 10:58 -0400, Steve wrote: >>> 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. I assume this has to do with how >>> the kernel handles re-direction. Is it possible to catch these >>> modifications? >>> >>> Thanks, >>> Steve >> >> What are your rules? You should catch these on open() >> of /file/to/watch, right? >> >> -tim > > I am seeing this as well with the .42 kernel and audit-1.2.4-1. Not sure > when this might have broken, but its broke now. > > It seems if you set a watch on /file/to (to use your example above), > then you are getting the opens that bash does, although the PATH record > shows the item as "/file/to/watch". > > So watching the parent directory will audit redirect shell magic, but > watching the target of that redirection will not audit that same magic. > > Mike Oh, and it turns out if the action fails, then the watch on the target of redirection will get audited. So if you echo "123" > not_writable_file, and you have a watch on 'not_writable_file', you will see an audit record, but if the write is successful, then you don't see it. Mike