Bypassing audit's file watches

Bypassing audit's file watches

[Steve]

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

Re: Bypassing audit's file watches

[Timothy R. Chavez]

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

Re: Bypassing audit's file watches

[Michael C Thompson]

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

Re: Bypassing audit's file watches

[Michael C Thompson]

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

Re: Bypassing audit's file watches

[Amy Griffis]

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

Re: Bypassing audit's file watches

[Steve]

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.

Steve

Re: Bypassing audit's file watches

[Timothy R. Chavez]

On Fri, 2006-07-07 at 22:00 -0400, Amy Griffis wrote:
<snip>
> 
> 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
> 

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.

-tim

Re: Bypassing audit's file watches

[Amy Griffis]

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

Re: Bypassing audit's file watches

[Michael C Thompson]

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