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 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.

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

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.