From: Steve Grubb <sgrubb@redhat.com>
To: linux-audit@redhat.com
Subject: Re: path watcher
Date: Fri, 12 Sep 2014 13:35:48 -0400 [thread overview]
Message-ID: <2095364.4DrZPs0qDA@x2> (raw)
In-Reply-To: <53F7624C.2000903@oracle.com>
Hello,
I had hoped some kernel guys would have jumped in here to answer...but I'll
take a stab at it.
On Friday, August 22, 2014 04:31:24 PM John Haxby wrote:
> We have an internal group auditing updates to files but who would like
> to be able to monitor the actual modification rather than the possible
> intent to modify.
That would be a nice addition.
> The example they gave is that some program opens a file
> O_WRONLY|O_APPEND but in most cases it does not subsequently write to
> the file. For them, the usual auditctl -p path -w wa causes lots of
> false positives.
I have asked some problematic apps to open readonly and then change flags when
they decide they need to write. Some people comply, others can't believe I
even asked them to do it.
> Historically, I know, that -w wa is triggered by the open(2) flags
> rather than actual modifications because "[t]he read & write syscalls
> are omitted from this set since they would overwhelm the logs." Reading
> this again now, it looks a little specious as it seems quite easy to
> overwhelm the logs anyway.
>
> Is there any reason why a file watcher should not use the fsnotify
> FS_ACCESS/MODIFY/ATTRIB masks before I go haring off to try to implement
> that?
I don't know the particulars. But for auditing purposes, we'd only want 1
event no matter how many times they wrote. If the w/r flags could be cleaned up
to be accurate and not signal just the intent, I think that would be good.
However, I am sure there are tricky corner cases such as mmapped files that
also need to be accounted for.
Steve
prev parent reply other threads:[~2014-09-12 17:35 UTC|newest]
Thread overview: 2+ messages / expand[flat|nested] mbox.gz Atom feed top
2014-08-22 15:31 path watcher John Haxby
2014-09-12 17:35 ` Steve Grubb [this message]
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=2095364.4DrZPs0qDA@x2 \
--to=sgrubb@redhat.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.