On Wed, 19 Mar 2008 13:40:21 EDT, Steve Grubb said: > On Wednesday 19 March 2008 13:12:22 Linda Knippers wrote: > > Rather than using the key for two purposes and introducing special key > > words, couldn't an admin just tell the IDS which he's are of interest? > > And what the priority of each one is? > > The problem is that you can tell the IDS that you want any reads > of /opt/my-secrets, but unless you have a matching audit rule you will not > get any records. This allows you to make sure you have a watch paired with > its meaning.
You have this backwards. If you have a "special" watch on /foo/bar, and you see an event arrive, the IDS should already know that /foo/bar is special and handle it accordingly, and it doesn't need to be told "this is special" in the audit record. One can make the case that it's *helpful* so that the IDS can note "Oh yes, this is a special file, and the audit record says it's special, so it matches". However, *no* amount of special tagging will allow the IDS to disambiguate these two cases: 1) An audit rule was set, but no events generated because no activity matched. 2) An audit rule wasn't set at all. "unless you have a matching audit rule you will not get any records" means exactly that - so tagging the records you don't receive isn't useful. There *is* the more general case of "I had a generic rule and a special watch and *both* fired" - but that problem is in no way IDS specific, but applies to *any* time that an event triggers more than one rule. We shouldn't be coding IDS-specific solutions to the general problem.
pgpdiLuGdAKcJ.pgp
Description: PGP signature
-- Linux-audit mailing list [email protected] https://www.redhat.com/mailman/listinfo/linux-audit
