From mboxrd@z Thu Jan 1 00:00:00 1970 From: Steve Grubb Subject: Re: [PATCH 2/2] Audit: remove the limit on execve arguments when audit is running Date: Mon, 8 Oct 2007 20:17:45 -0400 Message-ID: <200710082017.46614.sgrubb@redhat.com> References: <1191360589.9506.34.camel@localhost.localdomain> <200710081741.42819.sgrubb@redhat.com> <470AB2FB.7020104@hp.com> Mime-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Return-path: In-Reply-To: <470AB2FB.7020104@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@redhat.com, a.p.zijlstra@chello.nl List-Id: linux-audit@redhat.com On Monday 08 October 2007 18:45:15 Linda Knippers wrote: > > Well, I take this one to be the same as PATH records. Sometimes you get > > 1, sometimes 2, sometimes 3. > > But for any given system call, wouldn't you always get the same number > of PATH records? Maybe, sometimes you get a socket address record, too/instead of. The point is that you have no idea how many of them you are going to get without some analysis. > With PATH records, there's an item count in the SYSCALL record and > each PATH record says which one it is, so its possible to verify that > you've gotten them all. The way these get split, there is no way to know ahead of time how many you are going to get. These are being split as they are being output. The item count displayed in syscall is incremented as each aux record data is added to the context. So, there's no performance cost for displaying this. We could add an item parameter, but that only gives you sequence information. But you could infer the sequence information by the argument's number - it continually increments. If a record ends and a347 and the next one begins at a895, then you are missing one or more records. But even then, I don't think that's possible unless someone's tampered with the logs. If any allocation can't be done, the syscall is failed. So, the only question is what happens if the netlink queue has a problem sending to user space? Well, you get a syslog message and the kernel follows the failure action set by the admin - just as it would for any event. > I don't see the same type of information for the arguments so its not > possible to know if you've got a complete audit trail. When it moves on to another record type, you've got them all. -Steve