From: Steve Grubb <sgrubb@redhat.com>
To: linux-audit@redhat.com
Subject: Re: Excluding stat syscall logging for specific path
Date: Fri, 29 Apr 2016 14:48:51 -0400 [thread overview]
Message-ID: <132907641.2oh64C0JXm@x2> (raw)
In-Reply-To: <5723A4F1.1030001@gmail.com>
On Friday, April 29, 2016 09:16:17 PM Vincas Dargis wrote:
> 2016.04.29 21:00, Steve Grubb rašė:
> > On Friday, April 29, 2016 08:56:26 PM Vincas Dargis wrote:
> >> When playing/learning with auditd, I wanted to log events when apache
> >> fails to access file.
> >>
> >> Here's the rules I used in Debian Wheezy (same on Jessie and and current
> >> latest Testing):
> >>
> >> -a exit,never -F arch=b64 -S stat -F path=/var/www/server-status -k web
> >> -a exit,always -F arch=b64 -S stat -F uid=www-data -F success=0 -k web
> >>
> >> /var/www/server-status file is non-existant,
> >
> > Is it a symlink? If it really doesn't exist, then there is no inode to
> > match against.
>
> Oh...
>
> No, there is no such file at all, and shouldn’t be, but apache2 tries to
> check it, hence success=0 case is spammed into then logs.
Normally ENOENT failures are not a security concern. Normally EACCES and EPERM
are what attempted security policy violations return with. There is an inode
in that case.
> Same with
> .htaccess files that apache2 tries to find in every directory...
>
> I though it is possible to exclude stat calls with that path as argument to
> the syscall, but if it actually needs physical inode... then I guess it
> makes sense why it does not work for me.
>
> I wanted to _ignore_ some known stat/open failures for non-existant files,
> to recap.
The granularity won't allow it unless you can find another unique attribute to
weed these out.
> > What kernel are you using?
>
> 3.2 and 3.16 for sure, and I believe I tested on Debian Testing so it should
> be 4.5 currently.
OK. There were some older kernels where this didn't work right and thought
that might be relevant. But it turns out that kernel doesn't matter this time.
> P.S. should I reply to all or just the list?
Doesn't matter. Mailman usually does the right thing.
-Steve
--
Linux-audit mailing list
Linux-audit@redhat.com
https://www.redhat.com/mailman/listinfo/linux-audit
next prev parent reply other threads:[~2016-04-29 18:48 UTC|newest]
Thread overview: 5+ messages / expand[flat|nested] mbox.gz Atom feed top
2016-04-29 17:56 Excluding stat syscall logging for specific path Vincas Dargis
2016-04-29 18:00 ` Steve Grubb
2016-04-29 18:16 ` Vincas Dargis
2016-04-29 18:48 ` Steve Grubb [this message]
2016-04-29 19:05 ` Vincas Dargis
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=132907641.2oh64C0JXm@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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox