From mboxrd@z Thu Jan 1 00:00:00 1970 From: Matthew Booth Subject: A combined audit event message Date: Fri, 27 Feb 2009 21:21:37 +0000 Message-ID: <49A85961.4070007@redhat.com> Mime-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Return-path: Received: from mbooth.laptop (vpn-6-8.fab.redhat.com [10.33.6.8]) by ns3.rdu.redhat.com (8.13.8/8.13.8) with ESMTP id n1RLLdJW022793 for ; Fri, 27 Feb 2009 16:21:40 -0500 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 List-Id: linux-audit@redhat.com I've been looking into tuning an audit events analysis tool which receives audit records over the network from a large number of systems. It turns out that the most significant overhead (by far) on the collection system is in stitching records from a single event back together. This has lead me to explore combining records on the host before sending them out. I'm currently intending to produce messages like this: audit(1235768839.011:68): type=SYSCALL arch=40000003 syscall=5 success=yes exit=3 a0=ad9c00 a1=8000 a2=1 a3=bfefd2d0 items=1 pid=6312 auid=500 uid=0 gid=0 euid=0 suid=0 fsuid=0 egid=0 sgid=0 fsgid=0 comm="echo" exe="/bin/echo" | type=CWD cwd="/root" | type=PATH name="/usr/lib/locale/locale-archive" flags=101 inode=126312 dev=03:01 mode=0100644 ouid=0 ogid=0 rdev=00:00 This seems considerably nicer than snare: cent4.intersectalliance.com LinuxKAudit criticality,3 event,execve,20080613 16:06:29 uid,0,root gid,0,root euid,0,root egid,0,ro ot process,2971,ls return,0,yes a0,8775a68 a1,875ec80 a2,8759448 a3,875ec80 arch,40000003 auid,40000003 cwd,/var/log/audit dev,fd:00 dev:1,fd:00 exe,/bin/ls flags,101 flags:1,101 fsgid,0,root fsuid,0,root inode,97968 inode:1,146913 items,2 mode,0100755 mode:1,0100755 name,/bin/ls ogid,0,root ogid:1,0,root ouid,0,root ouid:1,0,root rdev,00:00 rdev:1,00:00 sgid,0,root suid,0,root which just munges all the fields together. It also has the advantage of being extremely fast to generate from the existing messages without any memory allocation or copying. Has anybody given this any thought? Has anybody else got a similar format in the works/field? Thanks, Matt -- 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