From mboxrd@z Thu Jan 1 00:00:00 1970 From: Steve Grubb Subject: Re: Set audisp plugin filters Date: Wed, 12 Apr 2017 12:45:47 -0400 Message-ID: <2095493.9BRLS0f1nT@x2> References: Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Return-path: In-Reply-To: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: linux-audit-bounces@redhat.com Errors-To: linux-audit-bounces@redhat.com To: linux-audit@redhat.com Cc: Eytan Naim List-Id: linux-audit@redhat.com On Wednesday, April 12, 2017 4:28:02 AM EDT Eytan Naim wrote: > I am currently developing an audisp plugin that should be as effective as > possible. Therefore, I want to set my own set of filtering rules (2-3 > syscalls) and I don't want to get any other audit events from the audisp > itself 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. > , - I assumed it is possible to set my own plugin rules but I couldn't find > it in the audit documentation (Linux Audit API) 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. > nor any other audisp plugins examples. Is it even possible? If not, is it > possible to run an auditd of my own in parallel with the original auditd? Not exactly. There is a multicast socket with lower reliability guarantees but you get the same events that auditd sees. > I assume each auditd can define its own set of audit rules. - Am I right? Nope. -Steve