From mboxrd@z Thu Jan 1 00:00:00 1970 From: LC Bruzenak Subject: Re: [PATCH] Add auditd listener and remote audit protocol Date: Thu, 14 Aug 2008 16:58:56 -0500 Message-ID: <1218751136.7022.206.camel@homeserver> References: <200808142143.m7ELh0MP028560@greed.delorie.com> Mime-Version: 1.0 Content-Type: text/plain Content-Transfer-Encoding: 7bit Return-path: In-Reply-To: <200808142143.m7ELh0MP028560@greed.delorie.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: DJ Delorie Cc: linux-audit@redhat.com List-Id: linux-audit@redhat.com On Thu, 2008-08-14 at 17:43 -0400, DJ Delorie wrote: > Second in a series, a bit bigger than the first one. > (http://www.redhat.com/archives/linux-audit/2008-August/msg00070.html) > > The goal of this patch is to add the server side of the remote logging > feature. To this end, a new auditd-listener.c is added which listens > on a TCP port for connections from other systems' audisp-remote > plugins. A new (private) protocol is added which prepends each > message with a header, giving length, status, version, and sequence > information. Each message begets a reply from the server, so we can > pass along status like "disk full" or "ok". Currently, these call a > set of stub functions, as the details of performing appropriate > actions from the plugin are yet to be decided. > > The remote plugin has a new option "format" for "ascii" or "managed" > to choose between the old protocol (ascii strings) and the new one > (the header with ACK, default). > > The listener will accept either format. It has new options for the > listen port, accept queue size, and acceptable client-side ports. > > Comments? > > DJ Sorry to be dense, but if it isn't too much trouble would you mind supplying an example use-case for this new capability? I went back and read the supplied link but it isn't clear to me how to take advantage of this, and I suspect it is important. What I'm getting is that in addition to kernel-generated local events the auditd would also receive signals as well as tcp-based events from other sources. Would this be the way of implementing multi-source audit aggregation or is it something different? Thx, LCB. -- LC (Lenny) Bruzenak lenny@magitekltd.com