Re: [RFC] programmatic IDS routing
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