Implementing audit rules (/etc/audit/audit.rules) effectively

[Jan Lieskovsky]

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?

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:

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

Thank you for your time & possible hints in advance.

Regards, Jan.
--
Jan iankko Lieskovsky / Red Hat Security Technologies Team

[*] Not familiar with audit internals, but translating the request to log / audit
    the event of particular system call occurrence from the Linux kernel PoV's
    it looks this might correspond to the problem of searching for a key / value
    in the hash table (having particular system call occurred, insert new entry
    under particular hash table's field taking -k keyname argument as the hash
    table key). If this analogy is at least a bit appropriate, the all -S's arguments
    case above would correspond to a hash table having just one value for each key,
    while separating the desired -S arguments into multiple rows would mean to
    have a hash table where one key (-k keyname) would have bucket containing
    multiple values (e.g. array of them). In this case to locate the particular
    value would mean to locate the bucket in the hash table & then subsequently
    yet locate the proper value in that array of items (which seems to be more
    time / operation expensive than the case of one rule having multiple -S arguments).
    Thus could audit upstream clarify, if there's some performance penalty in
    the case of multiple -S being split / spread across multiple rules?