From mboxrd@z Thu Jan 1 00:00:00 1970 From: Eric Paris Subject: Re: [RFC] Virtual Key Fields Date: Mon, 24 Mar 2008 09:42:14 -0400 Message-ID: <1206366134.3192.14.camel@localhost.localdomain> References: <200803240927.35073.sgrubb@redhat.com> Mime-Version: 1.0 Content-Type: text/plain Content-Transfer-Encoding: 7bit Return-path: In-Reply-To: <200803240927.35073.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 On Mon, 2008-03-24 at 09:27 -0400, Steve Grubb wrote: > Hi, > > Based on the discussion last week, I'd like to propose a technique of allowing > the appearance of multiple key fields without having to make changes in the > kernel. The kernel has one key field associated with each audit rule. It > doesn't look at the field's contents for anything. A patch will be submitted > for 2.6.26 kernel increasing the size of string the kernel will accept. The > kernel will still allocate the minimum memory needed to hold the string. I really like it. I think it is a good solution to the problem you were trying to solve. > Auditctl will also allow delete all rules matching a key. This will allow the > admin or a program to delete a set of rules related to just a particular key > and leave all other rules intact. How does this work? This is a completely new concept and it seems like it should be a second patch after you have multiple keys in to start with. auditctl -a exit,always -w /tmp/file1 -k file1 -k shared-key auditctl -a exit,always -w /tmp/file2 -k file2 -k shared-key now if I say (and i'm just guessing your new syntax): auditctl -d -k shared-key what do I end up with? no rules? still 2 rules but without the -k shared-key? I really think this part of the proposal needs to be explained a whole lot more before I buy into it. I'm scared of trying to remove rules by key and getting unanticipated results.... -Eric