From mboxrd@z Thu Jan 1 00:00:00 1970 From: Steve Grubb Subject: Re: Audit for live supervision Date: Tue, 19 Aug 2008 14:39:50 -0400 Message-ID: <200808191439.50621.sgrubb@redhat.com> References: <200808140914.07779.kayhayen@gmx.de> <200808191047.27582.sgrubb@redhat.com> <200808192023.21305.kayhayen@gmx.de> Mime-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Return-path: In-Reply-To: <200808192023.21305.kayhayen@gmx.de> 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: Kay Hayen Cc: linux-audit@redhat.com, alex@segv.de List-Id: linux-audit@redhat.com On Tuesday 19 August 2008 14:23:21 Kay Hayen wrote: > > > > libaudit should pull complete events from the kernel unless an execve > > > > has an excessive number of arguments or large sized arguments. > > > > > > I read that as that we can use the netlink socket with the libaudit > > > directly, which sort of could be exactly what we want. That would mean > > > we wouldn't use audit user space (processes) at all, right? > > > > True. You would have to load your own rules since that is done by the > > audit user space. > > Can you confirm that two processes opening netlink sockets for audit > information get the same messages? Only one audit pid is allowed for security purposes. > I am under the impression that the kernel doesn't maintain per socket > configuration, does it? Nope, it only allows one. > If that were the case, we would simply co-exist with auditd and let it do > its logging, etc. and benefit from it, and its ability to load the rules If you want to co-exist with auditd, then you want to write your own audispd. I pointed you to the skeleton.c code in the other email. > > events. wrt auparse (if that's what you meant) you just run the data > > through: > > > > asprintf(&v, "type=%s msg=%.*s\n", type, e->hdr.size, e->data); > > > > and "v" has the string ready for auparse use. asprinf() allocates memory, > > so watch that it doesn't create a memory leak. > > That's very sweet. Where would you expect the pitfalls? I mean, it can't be > so easy. :-) No pitfalls except watching for memory leaks. Audispd used the same code. -Steve