Re: [RFC] programmatic IDS routing

[Eric Paris <eparis@redhat.com>]

On Wed, 2008-03-19 at 17:31 -0400, Linda Knippers wrote:
> Steve Grubb wrote:

> > By using the key field, its in plain sight and done with purpose. Not enough 
> > events to trap something important, widen it in audit.rules and you also know 
> > that this will send more to disk. No suprises there.
> 
> I'm actually in favor of using the key, just in using it like its used
> today.  All the capp watches have unique keys, and an admin could create
> more/different rules with different keys.  I think that the IDS
> should have different configuration information to tell it what to look
> for and what to do with it, rather than embedding it into a short field
> in the audit record.  What if other plug-ins also want to use that
> field?

So maybe all we need is for the ids config file needs to be of the form

key type priority

so I can set up my audit rule however I want say

-a always,exit -F perms=wa -F auid>=500 -F exit=-EPERM -F dir=/etc -k 500EPERM
-a always,exit -F perms=wa -F subj_role=webadmin_r -F exit=-EPERM -k webadminEPERM

And my ids config file would look like:

500EPERM	file	med
webadminEPERM	exec	high

And on startup the ids can easily look to see if 500EPERM and
webadminEPERM are actually keys to real rules just for sanity sake.  Is
the reverse mapping from key to ids action really so expensive that this
is unreasonable?

I tend to also agree with the part of the discussion which says that it
isn't audit's place to decide that some rules are meant for disk and
some rules aren't.  Unless we add some new explicit rule syntax for just
that case.....

-Eric