Re: Bypassing audit's file watches

[Amy Griffis <amy.griffis@hp.com>]

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.

Amy