Bypassing audit's file watches

DISCUSSION Steve 4 participants 9 messages Jul 7, 2006 – Jul 11, 2006

Share & tools

Steve

author

2006-07-07 14:58 UTC #0 lore raw

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

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

Timothy R. Chavez

2006-07-07 15:59 UTC #1 lore raw

Quoted 8 lines · 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

Quoted 7 lines

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

Michael C Thompson

2006-07-07 16:09 UTC #2 lore raw

Quoted 11 lines · Timothy R. Chavez

Quoted 10 lines · 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?

Quoted 7 lines

Quoted 2 lines
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

Michael C Thompson

2006-07-07 16:21 UTC #3 lore raw

Quoted 20 lines · Michael C Thompson

Quoted 11 lines · Timothy R. Chavez
Quoted 10 lines · 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?
Quoted 7 lines
Quoted 2 lines
Thanks,
Steve
What are your rules? You should catch these on open() of /file/to/watch, right?
-tim

Quoted 7 lines

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

Amy Griffis

2006-07-08 02:00 UTC #4 lore raw

In reply to Steve

Steve wrote: [Fri Jul 07 2006, 10:58:42AM EDT]

Quoted 11 lines

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

Steve

author

2006-07-10 11:32 UTC #5 lore raw

Quoted 7 lines · Amy Griffis

Steve wrote: [Fri Jul 07 2006, 10:58:42AM EDT]
Quoted 6 lines
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

Quoted 7 lines

Quoted 3 lines
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

Timothy R. Chavez

2006-07-10 15:16 UTC #6 lore raw

In reply to Amy Griffis

On Fri, 2006-07-07 at 22:00 -0400, Amy Griffis wrote:
<snip>

Quoted 9 lines

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.

Quoted 7 lines

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

Amy Griffis

2006-07-10 22:32 UTC #7 lore raw

Steve wrote: [Mon Jul 10 2006, 07:32:26AM EDT]

Quoted 12 lines

Quoted 11 lines · Amy Griffis
Steve wrote: [Fri Jul 07 2006, 10:58:42AM EDT]
Quoted 10 lines
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

Quoted 7 lines

Quoted 5 lines
Quoted 1 line
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]

Quoted 3 lines

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.

Quoted 1 line

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

Michael C Thompson

2006-07-11 15:07 UTC #8 lore raw

Quoted 30 lines · Amy Griffis

Steve wrote: [Mon Jul 10 2006, 07:32:26AM EDT]
Quoted 8 lines
Quoted 7 lines · Amy Griffis
Steve wrote: [Fri Jul 07 2006, 10:58:42AM EDT]
Quoted 6 lines
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
Quoted 7 lines
Quoted 6 lines
Quoted 3 lines
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]
Quoted 3 lines
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.

Quoted 6 lines

Quoted 1 line
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