All of lore.kernel.org
 help / color / mirror / Atom feed
From: Steve Grubb <sgrubb@redhat.com>
To: linux-audit@redhat.com
Subject: Re: Auditd filtering
Date: Sat, 25 Jun 2011 14:05:14 -0400	[thread overview]
Message-ID: <201106251405.15316.sgrubb@redhat.com> (raw)
In-Reply-To: <3E9C7EEE1A67A14C9C668E9A4774E230EF3C2052A1@EXVMBX003-3.exch003intermedia.net>

Hello,

Missed this email and just noticed it. Hope the discussion is still of use to you.

On Tuesday, June 07, 2011 12:23:41 PM Nick Stires wrote:
> I started with a generic filter for all syscall events, this cut it down
> adequately, but we no longer captured the items we wanted to.

I would probably not approach the problem that way. You might look at the stig.rules 
file, which I consider probably the best sample to look at.
 
> Here's some example logs for the two events we are trying to trim down:
> 
> ################
> ################
> Netstat sample
> ################
> ################
> type=SYSCALL msg=audit(1307462086.972:1619017): arch=c000003e syscall=2
> success=no exit=-2 a0=6d9c790 a1=0 a2=0 a3=3074f234f3 items=2 ppid=4945
> pid=32700 auid=4294967295 uid=0 gid=0 euid=0 suid=0 fsuid=0 egid=0 sgid=0
> fsgid=0 tty=(none) ses=4294967295 comm="netstat" exe="/bin/netstat"
> subj=kernel key=(null) 

This is saying it returned ENOENT. That meand you are probably filtering all opens with 
success = no. Glibc attempts to open a lot of different files when a program is started. 
Most of these files don't exist. Is that really anything useful to capture? In the stig 
rules, I only look for opens that return EPERM or EACESS because those are the ones 
where DAC or MAC policy has been enforced against a processes attempts. We also have a 
nother decision as to whether or not you want system processes included in the audit 
or just failed opens that directly result from a user. The stig rules file only gets 
the ones that start by human invokaction.


> type=CWD msg=audit(1307462086.972:1619017): cwd="/"
> type=PATH msg=audit(1307462086.972:1619017): item=0
> name="/usr/share/locale/en.utf8/LC_MESSAGES/net-tools.mo" type=PATH
> msg=audit(1307462086.972:1619017): item=1
> name="/usr/share/locale/en.utf8/LC_MESSAGES/net-tools.mo"
> 
> ################
> ################
> Ganglia Sample
> ################
> ################
> type=SYSCALL msg=audit(1307462163.369:1620406): arch=c000003e syscall=2
> per=400000 success=no exit=-2 a0=2aaab81124b8 a1=0 a2=1b6 a3=0 items=2
> ppid=678 pid=681 auid=1002 uid=1002 gid=100 euid=1002 suid=1002 fsuid=1002
> egid=100 sgid=100 fsgid=100 tty=(none) ses=641 comm="java"
> exe="/usr/java/jdk1.6.0_24/bin/java" subj=kernel key=(null) 

This one again is a ENOENT return code. So, this is the same as the above discussion.


> Exemption rules:
> # a0=0x413586 appears to prevent proc tcp6 messages in the netstat sections
> -a exit,never -F a0=0x413586 -F success=0
> -a exit,never -F exit=-6 -F success=0
> -a exit,never -F exit=-13 -F success=0

This one ^^ is interesting...it means you don't want any event where the kernel 
blocked access due to permissions. I would think this is one of the events you are 
interested in.


> -a entry,never -S 159
> # UID 1002 = ganglia user. These do not work as intended.
> -a user,never -F auid=1002
> -a user,never -F uid=1002

 These last 2 would only work if ganglia sends audit events. So, you probably want to 
delete them.

> Any ideas on how I can target these audit logs for filtering?

I'd probably recommend rewriting your audit rules. However, if you just want a never 
rule, its probably something like:

-a never,exit -F arch=b32 -S open -S openat -F exit=-ENOENT
-a never,exit -F arch=b64 -S open -S openat -F exit=-ENOENT

-Steve

      reply	other threads:[~2011-06-25 18:05 UTC|newest]

Thread overview: 2+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2011-06-07 16:23 Auditd filtering Nick Stires
2011-06-25 18:05 ` 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=201106251405.15316.sgrubb@redhat.com \
    --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.