From mboxrd@z Thu Jan 1 00:00:00 1970 From: Valdis.Kletnieks@vt.edu Subject: Re: [RFC] programmatic IDS routing Date: Wed, 19 Mar 2008 14:18:12 -0400 Message-ID: <29287.1205950692@turing-police.cc.vt.edu> References: <200803191302.48434.sgrubb@redhat.com> <47E14976.9050308@hp.com> <200803191340.22092.sgrubb@redhat.com> Mime-Version: 1.0 Content-Type: multipart/mixed; boundary="===============1797847262==" Return-path: In-Reply-To: Your message of "Wed, 19 Mar 2008 13:40:21 EDT." <200803191340.22092.sgrubb@redhat.com> List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: linux-audit-bounces@redhat.com Errors-To: linux-audit-bounces@redhat.com To: Steve Grubb Cc: Linux Audit List-Id: linux-audit@redhat.com --===============1797847262== Content-Type: multipart/signed; boundary="==_Exmh_1205950692_2991P"; micalg=pgp-sha1; protocol="application/pgp-signature" Content-Transfer-Encoding: 7bit --==_Exmh_1205950692_2991P Content-Type: text/plain; charset=us-ascii 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. --==_Exmh_1205950692_2991P Content-Type: application/pgp-signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.8 (GNU/Linux) Comment: Exmh version 2.5 07/13/2001 iD8DBQFH4VjkcC3lWbTT17ARAkNnAJ9/r2eHbAqmEXMLBvZgYZLmPbNjsQCdFj42 CTvZdopTiQAmwoLH5FDOzzM= =z86Y -----END PGP SIGNATURE----- --==_Exmh_1205950692_2991P-- --===============1797847262== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline --===============1797847262==--