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