public inbox for linux-audit@redhat.com
 help / color / mirror / Atom feed
From: Steve Grubb <sgrubb@redhat.com>
To: linux-audit@redhat.com
Cc: Jan Lieskovsky <jlieskov@redhat.com>
Subject: Re: Implementing audit rules (/etc/audit/audit.rules) effectively
Date: Wed, 05 Nov 2014 13:51:59 -0500	[thread overview]
Message-ID: <3631170.9jbyyIp8pf@x2> (raw)
In-Reply-To: <1142172061.2138213.1415212751528.JavaMail.zimbra@redhat.com>

On Wednesday, November 05, 2014 01:39:11 PM Jan Lieskovsky wrote:
> Hello folks,
> 
>   within the effort to provide an implementation for some task
> implying from my daily job recently I started to face the following
> question related with auditd - how to write audit rules in most
> effective way. I am mainly interested if there's some comparison / research
> wrt to if there's is some performance penalty when (syscall, but
> in general case doesn't need to be limited to syscall calls) audit
> rules are created in the way having just one syscall rule (one -S argument
> is provided per audit rule) versus the case when there are more
> (compatible) -S arguments provided simultaneously in the particular
> audit.rules row?

Yes there has. The answer is combine as many syscalls as possible into each 
rule. To see why, look at this code:

http://lxr.free-electrons.com/source/kernel/auditsc.c#L747

Basically you have a for loop over each rule and on line 765 it checks by 
"anding" the syscalls in the rule. If no match iterate again. So, by 
increasing the rules, you increase the iterating for each and every syscall 
made whether its of interest or not.


> To provide an example, let's suppose the *chown category of rules:
> * the "all-in-one" case:
> 
>   -a always,exit -F arch=b32 -S chown -S fchown -S fchownat -S lchown -F
> auid>=500 -F auid!=4294967295 -k perm_mod
> 
> vs
> 
> * the "one-rule-per-one-row" case:

The first is the recommended format and that is also the way that all sample 
rules, such as the stig.rules, is written.
 
>   -a always,exit -F arch=b32 -S chown    -F auid>=500 -F auid!=4294967295 -k
> perm_mod -a always,exit -F arch=b32 -S fchown   -F auid>=500 -F
> auid!=4294967295 -k perm_mod -a always,exit -F arch=b32 -S fchownat -F
> auid>=500 -F auid!=4294967295 -k perm_mod -a always,exit -F arch=b32 -S
> lchown   -F auid>=500 -F auid!=4294967295 -k perm_mod
> 
> Does the fact how the -S arguments are layered across the
> /etc/audit/audit.rules file (IOW if being provided within one row or spread
> within multiple rows) have some (negative) impact on the audit system's
> efficiency? [*] If so, is there some way how to measure the performance
> penalty in the second case?

Yes. We have done it in the past to come up with the current recommendation.

-Steve

      reply	other threads:[~2014-11-05 18:51 UTC|newest]

Thread overview: 2+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
     [not found] <1533299638.2108662.1415210835257.JavaMail.zimbra@redhat.com>
2014-11-05 18:39 ` Implementing audit rules (/etc/audit/audit.rules) effectively Jan Lieskovsky
2014-11-05 18:51   ` 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=3631170.9jbyyIp8pf@x2 \
    --to=sgrubb@redhat.com \
    --cc=jlieskov@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