[RFC] programmatic IDS routing
Eric Paris
eparis at redhat.com
Wed Mar 19 21:41:07 UTC 2008
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
More information about the Linux-audit
mailing list