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 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.