From mboxrd@z Thu Jan 1 00:00:00 1970 From: Steve Grubb Subject: Re: [RFC] programmatic IDS routing Date: Thu, 20 Mar 2008 09:53:33 -0400 Message-ID: <200803200953.33566.sgrubb@redhat.com> References: <200803191302.48434.sgrubb@redhat.com> <200803191944.03857.sgrubb@redhat.com> <47E2676D.9020409@hp.com> Mime-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit Return-path: In-Reply-To: <47E2676D.9020409@hp.com> Content-Disposition: inline List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: linux-audit-bounces@redhat.com Errors-To: linux-audit-bounces@redhat.com To: Linda Knippers Cc: Linux Audit , Valdis.Kletnieks@vt.edu List-Id: linux-audit@redhat.com On Thursday 20 March 2008 09:32:29 Linda Knippers wrote: > Steve Grubb wrote: > > I wouldn't call this overloading the key field. The key field's purpose > > is to allow searches for groups of audit events. You've traditionally > > used this from the command prompt with ausearch. Now with the auparse > > library, it can be used programmatically for searching by more utilities. > > > > The way that it helps is that I can tell yes/no in 4 byte compares and > > without storing any linked lists, hashes, or binary trees. > > This optimization for a user-space component doesn't seem worth the hack. > You are overloading the field How is this overloading the field? What is your definition of the field? What are its legitimate uses? Is the admin not allowed to put anything they want in it, include text they'd like picked out in realtime? > > How do you do that remotely? > > Same way you would check that audit is running remotely. You can either > check the state of the target system or not, The answer is not. So, given that you can't probe the other end, you have no way to check the rules. > >> I guess Eric and I were both confused then by your comment about the > >> admin ending up with more audit events on disk than intended. > > > > -a always,exit -F perms=wa -F auid>=500 -F exit=-EPERM -F > > path=/etc/password > > > > and > > > > -w /etc/password > > > > collect entirely different amounts of data. > > So the admin would create the rule he wants, create a unique key and tell > the IDS what the key is and how it should react when it sees a record with > that key. Yes. What I want to do is also say that if you create your unique key a certain way, you get this additional benefit of realtime alerting or correlation. if you choose not to, then its treated as any other event. -Steve