Set audisp plugin filters

Set audisp plugin filters

[Eytan Naim]

[-- Attachment #1.1.1: Type: text/plain, Size: 936 bytes --]

Hi,

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, - I assumed it is possible to set my own plugin rules but I couldn't find it in the audit documentation (Linux Audit API) 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? I assume each auditd can define its own set of audit rules. - Am I right?

Thanks in advance,

[https://signature.imperva.com/assets/imperva-logo.png]
Eytan Naim | SW Engineer
eytan.naim@imperva.com<mailto:eytan.naim@imperva.com> | m: +972 50-225-8833
imperva.com<https://imperva.com> | facebook<https://www.facebook.com/imperva> | linkedin<https://www.linkedin.com/company/imperva> | twitter<https://twitter.com/imperva>


[-- Attachment #1.1.2: Type: text/html, Size: 4718 bytes --]

[-- Attachment #1.2: image001.png --]
[-- Type: image/png, Size: 1488 bytes --]

[-- Attachment #2: Type: text/plain, Size: 0 bytes --]

Re: Set audisp plugin filters

[Richard Guy Briggs]

On 2017-04-12 08:28, Eytan Naim wrote:
> Hi,

Hi Eytan,

> 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, - I assumed it is possible to set my own plugin rules but I couldn't find it in the audit documentation (Linux Audit API) nor any other audisp plugins examples. Is it even possible?

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.

> If not, is it possible to run an auditd of my own in parallel with the original auditd? I assume each auditd can define its own set of audit rules. - Am I right?

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.

> Eytan Naim | SW Engineer

- RGB

--
Richard Guy Briggs <rgb@redhat.com>
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

Re: Set audisp plugin filters

[Paul Moore]

On Wed, Apr 12, 2017 at 4:28 AM, Eytan Naim <eytan.naim@imperva.com> wrote:
> Hi,
>
> 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, - I assumed it is possible to set my own plugin rules but I couldn’t find it in the audit documentation (Linux Audit API) 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? I assume each auditd can define its own set of audit rules. – Am I right?

I'll let Steve Grubb respond with respect to the audit dispatcher, but
as far as the audit daemon is concerned you can currently only run one
instance at a time and only one set of audit filter rules that apply
to the entire system.

-- 
paul moore
www.paul-moore.com

--
Linux-audit mailing list
Linux-audit@redhat.com
https://www.redhat.com/mailman/listinfo/linux-audit

Re: Set audisp plugin filters

[Steve Grubb]

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