Steve Grubb wrote:
On Wednesday 19 March 2008 15:04:57 Linda Knippers wrote:
> I'm not sure why all of the above apply.
Because this IDS is part of the audit system.
Is there something that describes what you're building so we can
have the right context to comment on this? I assumed you were
building something that would be a dispatcher plug-in or something
rather than building something new into the core audit subsystem.
> If an IDS has a dependency on audit and specific audit rules to
get the
> information it needs, it can use the information in its config file to
> construct the audit rules it needs.
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.
An IDS should be able to be prodded to reload its rules. And it should
do something if it sees audit being disabled. If someone wants IDS
functionality, they'd probably be using the IDS to manage the files
they're watching so I don't think you'd have IDS watches and separate
audit watches.
> I don't think an IDS config file needs to be any more complicated than an
> audit rules, and in fact should be simpler.
I think it would be more complicated going down this path for a number of
reasons.
To me it seems more complicated to bundle everything together and
overload the key.
-- ljk
-Steve