From: Michael C Thompson <thompsmc@us.ibm.com>
To: Steve <m6x@ornl.gov>, "Timothy R. Chavez" <tinytim@us.ibm.com>,
linux-audit@redhat.com
Subject: Re: Bypassing audit's file watches
Date: Tue, 11 Jul 2006 10:07:01 -0500 [thread overview]
Message-ID: <44B3BE95.2060001@us.ibm.com> (raw)
In-Reply-To: <20060710223132.GA16657@dill.zko.hp.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
next prev parent reply other threads:[~2006-07-11 15:07 UTC|newest]
Thread overview: 9+ messages / expand[flat|nested] mbox.gz Atom feed top
2006-07-07 14:58 Bypassing audit's file watches Steve
2006-07-07 15:59 ` Timothy R. Chavez
2006-07-07 16:08 ` Michael C Thompson
2006-07-07 16:20 ` Michael C Thompson
2006-07-08 2:00 ` Amy Griffis
2006-07-10 11:32 ` Steve
2006-07-10 22:31 ` Amy Griffis
2006-07-11 15:07 ` Michael C Thompson [this message]
2006-07-10 15:16 ` Timothy R. Chavez
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=44B3BE95.2060001@us.ibm.com \
--to=thompsmc@us.ibm.com \
--cc=linux-audit@redhat.com \
--cc=m6x@ornl.gov \
--cc=tinytim@us.ibm.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.