* Implementing audit rules (/etc/audit/audit.rules) effectively [not found] <1533299638.2108662.1415210835257.JavaMail.zimbra@redhat.com> @ 2014-11-05 18:39 ` Jan Lieskovsky 2014-11-05 18:51 ` Steve Grubb 0 siblings, 1 reply; 2+ messages in thread From: Jan Lieskovsky @ 2014-11-05 18:39 UTC (permalink / raw) To: linux-audit 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? ^ permalink raw reply [flat|nested] 2+ messages in thread
* Re: Implementing audit rules (/etc/audit/audit.rules) effectively 2014-11-05 18:39 ` Implementing audit rules (/etc/audit/audit.rules) effectively Jan Lieskovsky @ 2014-11-05 18:51 ` Steve Grubb 0 siblings, 0 replies; 2+ messages in thread From: Steve Grubb @ 2014-11-05 18:51 UTC (permalink / raw) To: linux-audit; +Cc: Jan Lieskovsky 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 ^ permalink raw reply [flat|nested] 2+ messages in thread
end of thread, other threads:[~2014-11-05 18:51 UTC | newest]
Thread overview: 2+ messages (download: mbox.gz follow: Atom feed
-- links below jump to the message on this page --
[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 is a public inbox, see mirroring instructions for how to clone and mirror all data and code used for this inbox