From mboxrd@z Thu Jan 1 00:00:00 1970 From: Michael C Thompson Subject: Re: Bypassing audit's file watches Date: Tue, 11 Jul 2006 10:07:01 -0500 Message-ID: <44B3BE95.2060001@us.ibm.com> References: <44AE76A2.9050205@ornl.gov> <20060708020002.GA5350@dill.zko.hp.com> <1152544584.13544.11.camel@localhost.localdomain> <44AE76A2.9050205@ornl.gov> <20060708020002.GA5350@dill.zko.hp.com> <44B23ACA.10409@ornl.gov> <20060710223132.GA16657@dill.zko.hp.com> Mime-Version: 1.0 Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit 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 k6BF7Lng001421 for ; Tue, 11 Jul 2006 11:07:21 -0400 Received: from e2.ny.us.ibm.com (e2.ny.us.ibm.com [32.97.182.142]) by mx1.redhat.com (8.12.11.20060308/8.12.11) with ESMTP id k6BF7IYq027381 for ; Tue, 11 Jul 2006 11:07:18 -0400 Received: from d01relay02.pok.ibm.com (d01relay02.pok.ibm.com [9.56.227.234]) by e2.ny.us.ibm.com (8.12.11.20060308/8.12.11) with ESMTP id k6BF7DOt005591 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL) for ; Tue, 11 Jul 2006 11:07:13 -0400 Received: from d01av04.pok.ibm.com (d01av04.pok.ibm.com [9.56.224.64]) by d01relay02.pok.ibm.com (8.13.6/NCO/VER7.0) with ESMTP id k6BF7C0d255918 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for ; Tue, 11 Jul 2006 11:07:13 -0400 Received: from d01av04.pok.ibm.com (loopback [127.0.0.1]) by d01av04.pok.ibm.com (8.12.11.20060308/8.13.3) with ESMTP id k6BF7Cno001251 for ; Tue, 11 Jul 2006 11:07:12 -0400 In-Reply-To: <20060710223132.GA16657@dill.zko.hp.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: Steve , "Timothy R. Chavez" , linux-audit@redhat.com List-Id: linux-audit@redhat.com Amy Griffis wrote: > Steve wrote: [Mon Jul 10 2006, 07:32:26AM EDT] >> Amy Griffis wrote: >>> 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? >>> If you are missing events for open() calls, please let us know since >>> that would be a bug (versus a lacking feature). >> I am not seeing the open() or any other syscall records. > > The problem you're seeing is with audit's data collection during open() calls. > When open() is called with O_CREAT, but the file exists, audit collects the > wrong inode number for the call. I'll try to come up with a decent patch to fix > this. > > Timothy R. Chavez wrote: [Mon Jul 10 2006, 11:16:23AM EDT] >> I think this is a bug. We see audit records for a failed attempt at >> writing a file (e.g. chmod -w foo, echo "bar" > foo) via redirection, >> but not otherwise. > > This is interesting. You see a record for the failed attempt because the shell > tries again without the O_CREAT flag. > >>>From strace: > > open("/tmp/foo", O_WRONLY|O_CREAT|O_TRUNC|O_LARGEFILE, 0666) = -1 EACCES (Permission denied) > open("/tmp/foo", O_WRONLY|O_TRUNC|O_LARGEFILE) = -1 EACCES (Permission denied) > > So you should actually see 2 open() records in the failure case. As far as I can tell, if you have a watch on the file, you still do not see the success attempts (from an audit perspective) and you only see 1 open audit record, although you do get two different open() attempts. Resulting strace & audit from the same action: open("file", O_WRONLY|O_CREAT|O_TRUNC|O_LARGEFILE, 0666) = -1 EACCES (Permission denied) open("file", O_WRONLY|O_TRUNC|O_LARGEFILE) = -1 EACCES (Permission denied) type=SYSCALL msg=audit(1152367792.459:15443): arch=40000003 syscall=5 success=no exit=-13 a0=8dfa910 a1=8201 a2=0 a3=8201 items=1 ppid=12690 pid=12691 auid=0 uid=500 gid=500 euid=500 suid=500 fsuid=500 egid=500 sgid=500 fsgid=500 tty=pts1 comm="script" exe="/bin/bash" subj=root:staff_r:staff_t:s0-s15:c0.c255 key=(null) type=CWD msg=audit(1152367792.459:15443): cwd="/home/mcthomps" type=PATH msg=audit(1152367792.459:15443): item=0 name="file" inode=3375168 dev=03:03 mode=0100444 ouid=500 ogid=500 rdev=00:00 obj=root:object_r:user_home_dir_t:s0 There is only 1 audit record, while there are two open attempts. This is that O_CREAT problem. Note that the audit record here does _not_ have the O_CREAT flag (0100). If you would like to duplicate this, here are the steps to follow: # touch file # chmod -w file # echo -e '#!/bin/bash\necho 123 > file' > script.sh # chmod +x script.sh # auditctl -w `pwd`/file # strace -f ./script.sh Note that you should do the script action as non-root, since root can override normal DAC permissions. Mike