From: Michael C Thompson <thompsmc@us.ibm.com>
To: Michael C Thompson <thompsmc@us.ibm.com>
Cc: linux-audit@redhat.com
Subject: Re: Bypassing audit's file watches
Date: Fri, 07 Jul 2006 11:20:43 -0500 [thread overview]
Message-ID: <44AE89DB.9080102@us.ibm.com> (raw)
In-Reply-To: <44AE8715.5040309@us.ibm.com>
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
next prev parent reply other threads:[~2006-07-07 16:21 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 [this message]
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
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=44AE89DB.9080102@us.ibm.com \
--to=thompsmc@us.ibm.com \
--cc=linux-audit@redhat.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.