From mboxrd@z Thu Jan 1 00:00:00 1970 From: Matthew Booth Subject: Re: Cooked audit log format Date: Mon, 12 May 2008 16:02:36 +0100 Message-ID: <48285C0C.5070809@redhat.com> References: <482767E0.10506@redhat.com> <200805121043.17906.sgrubb@redhat.com> Mime-Version: 1.0 Content-Type: multipart/mixed; boundary="===============0909237609==" Return-path: In-Reply-To: <200805121043.17906.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@redhat.com List-Id: linux-audit@redhat.com This is an OpenPGP/MIME signed message (RFC 2440 and 3156) --===============0909237609== Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="------------enig45BF89055684B49E62AC9A67" This is an OpenPGP/MIME signed message (RFC 2440 and 3156) --------------enig45BF89055684B49E62AC9A67 Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: quoted-printable Steve Grubb wrote: >> Simple starters would include: >> * Translating the architecture and syscall names into human. >=20 > libauparse, ausearch, & ausyscall can do this. >=20 >> * Jumping one way or the other with the hex strings business >=20 > not sure what you mean by this. ausearch, aureport, & libauparse can ha= ndle=20 > them. Strings should be either always hex encoded, or always escaped=20 (preferably the latter). >> * Translating socket addresses into human. >=20 > libauparse, ausearch, and aureport all do this. >=20 >> * Translating timestamps into human. >=20 > libauparse, ausearch, and aureport all do this. No doubt, but I'm interested in a general agreement around the output,=20 not which tools can generate it. My customer is using a third party=20 audit tool to collate logs from a large number of sources including=20 Linux accounting logs, but also including HP-UX, Solaris, Windows, AIX,=20 door sensors, etc... There is currently no good steer for third party=20 tool vendors about what log format they should support, hence I have=20 recommended uncooked. However, the problem with uncooked logs is that=20 they are offensive to the human eye ;) This makes life difficult for an=20 operator presented with a bunch of logs to look at, which together form=20 some interesting event. >> * Ditching uninteresting records, such as PATH with no name for the >> dynamic linker, and 2 PATH records when execing a script. Oh, also: * Ditching CWD and making all PATH records absolute. >> with an ultimate goal of: >> * Defining an expected set of data for every system call and putting >> them all on a single line in a well defined format. >=20 > I have a feeling that too will become an abomination. aureport tries to= get=20 > the audit events down to the bare essentials. But what you wind up with= is=20 > something that makes you want more details. When you add more details y= ou=20 > feel like you want less. The goal is semi human-readability in a standard, machine-readable=20 format. So include all the abominable details, but at the end of the=20 line ;) And put everything on 1 line. And define exactly what will be on = that line, every time. >> Is anybody doing any work in this direction? >=20 > Not really. Part of the problem is that I occasionally hear complaints = about=20 > the audit format, but then no one that is actually /using/ the audit ou= tput=20 > is willing to help define what an auditor needs. I'd really like this t= o come=20 > from people who do this as their job.=20 >=20 > I can take a guess at what's needed. But I really want to hear it from = the=20 > Security Officer's perspective. >=20 > One thing that is on the TODO list is to make a output format that is l= ike=20 > strace for syscall records. At least people have experience reading str= ace=20 > output and it might help make one class of record easier to understand.= Doing=20 > this will be a big job, so I want to get some important things like rem= ote=20 > logging finished before jumping into it. >=20 I don't underestimate the size of the task: it's a huge mountain of=20 donkey work, but it really has to be done. And maintained... Matt --=20 Matthew Booth, RHCA, RHCSS Red Hat, Global Professional Services M: +44 (0)7977 267231 GPG ID: D33C3490 GPG FPR: 3733 612D 2D05 5458 8A8A 1600 3441 EA19 D33C 3490 --------------enig45BF89055684B49E62AC9A67 Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.5 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iD8DBQFIKFwQNEHqGdM8NJARAgGuAJ9g45HXc82R1Xr7aGSvfYak1fmSXQCeNwXM fL1cRxxOSHLsT+FC7p0ibgc= =MDZm -----END PGP SIGNATURE----- --------------enig45BF89055684B49E62AC9A67-- --===============0909237609== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline --===============0909237609==--