From mboxrd@z Thu Jan 1 00:00:00 1970 From: Steve Grubb Subject: Re: [PATCH] Add End of Event record Date: Thu, 27 Sep 2007 13:47:15 -0400 Message-ID: <200709271347.16110.sgrubb@redhat.com> References: <200709270916.43149.sgrubb@redhat.com> <1190911815.15596.43.camel@finch.boston.redhat.com> Mime-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Return-path: In-Reply-To: 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: linux-audit@redhat.com Cc: "Todd, Charles" List-Id: linux-audit@redhat.com On Thursday 27 September 2007 13:18:35 Todd, Charles wrote: > 1. A (pseudo-)RFC describing the dispatcher "protocol" What do you need to know? Plugins read from stdin, they must obey SIGHUP = and=20 SIGTERM, they must keep stdin empty. They can be sent either string data = or a=20 pseudo binary format straight from the audit daemon (I do not recommend t= hat=20 for anyone). The string format follows the guidelines laid out for the au= dit=20 parser library. > 2. A rigid, easily parsed record format - AUDIT_EOE might keep it easy > on the reporting subsystem That is defined in the audit parsing library specs (although it needs upd= ating=20 for the node field). As for EOE, I had planned to filter that out when=20 writing to disk as it just wastes disk space. The real issue is that for=20 realtime reactive systems, every second counts. This lets them start to t= ake=20 actions faster. For reporting, all events are on disk and the EOE can be=20 deduced. > 3. Administrative records are passed, perhaps at dispatchers startup an= d > at the start of a file when rotated, that documents which version of > auditd, uname -r, output of gnu_get_libc_version(), and the local syste= m > date/time. The auditd version is already recorded. uname -r output might be nice to = add.=20 I don't see why glibc version is needed. It has nothing to do with audit=20 rules or events (the kernel does, though). Local system time is already=20 recorded in every record. > The administrative record, when mentioning auditd's version, may even > indicate a "backward compatible to version..." so that 1.2.6 might stil= l > be able to parse 1.2.12, but as of 1.3 the format changed so backwards > compatability is broken. This is unnecessary since the audit daemon takes the event and writes it=20 straight to disk. The audit format should not be changing from name=3Dval= ue in=20 the foreseeable future. The nice thing is that if anyone wants to do something new, you can write= a=20 plugin to disassemble the native event and re-write it into any format yo= u=20 want. > My goal is this: 3 years from now, an employee is being investigated. > The investigator makes me pull up all the raw records from my network > and analyze them. =A0Now I've interpreted user names, group names, names and groups are the one thing that needs to be thought about. > syscalls,=20 libaudit has a full table > and hostnames during capture (ausearch -i), =20 hostnames are another thing to think about, but shouldn't be as troubleso= me as=20 users and groups. > but if the format changed through the years, I need to have analysis to= ols > be aware of the format. =A0This gets back to a previous posting I did > on "Offline audit trail analysis." -Steve