Re: [RFC] programmatic IDS routing

[Steve Grubb <sgrubb@redhat.com>]

On Wednesday 19 March 2008 15:48:54 Eric Paris wrote:
> > Then you surely have duplicate rules controlled by 2 systems. The first
> > rule in the audit.rules file is -D which would delete not only the audit
> > event rules for archival purposes, but any IDS placed rules. There is not
> > a simple way of deleting the rules placed by auditctl vs the ones placed
> > by the IDS. The IDS system would also need to be prodded to reload its
> > set of rules again.
>
> If someone does -D they lose no matter what no matter how we solve
> this  :)

Well, in the way I propose, all the rest of the lines of audit.rules sets it 
back up.


> I find it objectionable that they sysadmin has to learn some new
> arbitrary key requirements.

Its not arbitrary if it follows a defined and agreed upon pattern.  ;)

> Could the ids system parse its own configuration file and automatically
> generating audit.rules.ids which is just cat'ed onto the end of audit.rules
> for purposes of statup scripts and things like that?

I suppose it could, but then what if you wanted to do something complicated 
like:

-a always,exit -F perms=wa -F auid>=500 -F exit=-EPERM -F dir=/etc -k 
ids-file-med

or 

-a always,exit -F perms=wa -F subj_role=webadmin_r -F exit=-EPERM -k 
ids-file-med

In order to allow the expressiveness that auditctl rules could perform, you 
need to build this into the configuration that the IDS reads. As you add each 
capability, you suddenly realize you just wrote auditctl another way. So, its 
either do simplistic watches for the IDS or you wind up writing auditctl.

> Although admittedly I have no idea what happens if you do
>
> -a exit,always -S all -k hey2
> -a exit,always -S all -k key2

This would generate a lot of events, some would be trapped by the IDS, but 
none would fall into the watched file/exec/mkexe buckets of the IDS.

-Steve