From: Steve Grubb <sgrubb@redhat.com>
To: linux-audit@redhat.com
Cc: "Wyllie, Aaron" <Aaron.Wyllie@lpsvcs.com>
Subject: Re: Limiting Audit Logs For Specific Directories & Specific Error Codes
Date: Fri, 11 Dec 2009 14:40:30 -0500 [thread overview]
Message-ID: <200912111440.30258.sgrubb@redhat.com> (raw)
In-Reply-To: <FFA9EB335368E0429E5DE3C20D81B4959F6870A56E@JTCLPSMAIL02.lpsvcs.com>
On Friday 11 December 2009 01:20:49 pm Wyllie, Aaron wrote:
> Hi. I have a few basic questions.
>
> First, we have a particular piece of software that generates a lot of log
> entries for file deletes (successful & unsuccessful). I'd like to limit
> what is actually captured by excluding that directory.
>
> I'm thinking that I could add: -F dir!=/var/opt/xxx/xxx
>
> Would that prevent logging from anything recursively from that directory
> and below or do I need to set rules to specifically exclude for each file
> (which I may do anyways)? Is there a different/better means for doing
> this?
I think you want
-a exit,never -F dir=/var/opt/xxx/xxx
> The second question is events resulting from running 'ls -al' as a normal
> user 'su -' to root. This is generating a failed syscall error for
> getxattr with an error code of 61 (no data available). I'm assuming that
> this is because no extended attributes were set but, regardless, I'd like
> to avoid this.
>
> I have the following rules that I think may be logging this but I'm not
> sure:
>
> -a entry,always -F arch=b32 -S setxattr -S lsetxattr -S fsetxattr -S
> removexattr -S lremovexattr -S fremovexattr -k SYS_attribute -a
> entry,always -F arch=b32 -S creat -S open -S openat -S truncate -S
> ftruncate
>
> Would adding the following prevent these events from being logged or do I
> need to create a new rule(?): -F exit!=-61
Yes, that would do it. Also note that the exit code is not available for rules
on the entry filter. So, you need to change that, too.
> Lastly, is there any benefit associated with ordering the rules in
> audit.rules, i.e., are they applied in the order they are read?
They are in the order they are read in per each filter as long as you use the
'-a' operator. If you use '-A', then that rule goes to the front of the list
for the stated filter.
The only reason to order them is when you have a specific rule that you would
like to take priority over rules after it.
-Steve
prev parent reply other threads:[~2009-12-11 19:40 UTC|newest]
Thread overview: 2+ messages / expand[flat|nested] mbox.gz Atom feed top
2009-12-11 18:20 Limiting Audit Logs For Specific Directories & Specific Error Codes Wyllie, Aaron
2009-12-11 19:40 ` 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=200912111440.30258.sgrubb@redhat.com \
--to=sgrubb@redhat.com \
--cc=Aaron.Wyllie@lpsvcs.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.