On 2017-04-12 08:28, Eytan Naim wrote: Hi Eytan, There is only one set of rules. You may need to add extra functionality to your plugin to do additional filtering, but I'll defer to Steve who would be better able to advise. At the moment there can only be one audit daemon registered with the kernel at a time. There are ideas floating around to have more than one audit daemon running in the future, but that is specifically to support containers and is most likely to be tied to a single instance per user namespace with its own ruleset. I suspect is isn't the answer you were seeking. - RGB -- Richard Guy Briggs <rgb(a)redhat.com&gt; Sr. S/W Engineer, Kernel Security, Base Operating Systems Remote, Ottawa, Red Hat Canada IRC: rgb, SunRaycer Voice: +1.647.777.2635, Internal: (81) 32635

On Wednesday, April 12, 2017 4:28:02 AM EDT Eytan Naim wrote: This is not possible. There is one audit rule evaluator in the kernel. Any event generated by it will get written to disk and sent to all plugins. It is up to the plugins to filter events themselves. A long time ago, I was working on feeding an intrusion detection system. (I'm working my way back to intrusion detection and prevention but this time with better technology.) The way that I denoted events that were meant for the IDS system was to use keys with a special prefix of 'ids-'. Anything that did not have this prefix was discarded by the plugin. I have also considered asking if we could put a routing field in the event specifically for cases like this. There are times you want lots of information about something but its not actually meant to be logged. For example, you might want exit_group events which is not called out for in any security policy. So, you don't want to pollute the audit trail with those kind of events. I suppose this could be accomplished by using multiple keys with one having routing information. I don't exactly like that because it forces all keys associated with that event to get encoded and that takes up more disk space. Still mulling it over. Haven't solved it yet because I'm not quite ready to go back to IDS work just yet. The preferred way is drop your rules into /etc/audit/rules.d/ This will get picked up and loaded. If however you wanted load them programmatically, I would suggest looking over the autrace source code. https://github.com/linux-audit/audit-userspace/blob/master/src/autrace.c#L50 There's no guarantee that the rule won't get flushed by someone updating the rules with augenrules unless you put the audit system into immutable mode. Some people may not like that. Not exactly. There is a multicast socket with lower reliability guarantees but you get the same events that auditd sees. Nope. -Steve