public inbox for linux-audit@redhat.com
 help / color / mirror / Atom feed
From: LC Bruzenak <lenny@magitekltd.com>
To: Matthew Booth <mbooth@redhat.com>
Cc: Linux Audit <linux-audit@redhat.com>
Subject: Re: A combined audit event message
Date: Fri, 27 Feb 2009 16:12:35 -0600	[thread overview]
Message-ID: <1235772755.7212.50.camel@homeserver> (raw)
In-Reply-To: <49A85961.4070007@redhat.com>


On Fri, 2009-02-27 at 21:21 +0000, Matthew Booth wrote:
> 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
> 

Matt,

If you don't mind indulging me a moment...I am very interested in the
ultimate goal you stated, "tuning an audit events analysis tool which
receives audit records over the network from a large number of systems",
since that is where I am headed...

For example I see the following from an ausearch :
...
----
node=jcdx type=PATH msg=audit(02/27/2009 15:32:41.747:2986) : item=0
name=/var/log/audit/audit.log inode=375 dev=fd:00 mode=file,600
ouid=root ogid=root rdev=00:00
obj=system_u:object_r:auditd_log_t:s15:c0.c1023 
node=jcdx type=CWD msg=audit(02/27/2009 15:32:41.747:2986) :  cwd=/root 
node=jcdx type=SYSCALL msg=audit(02/27/2009 15:32:41.747:2986) :
arch=x86_64 syscall=open success=yes exit=4 a0=7fffe635efeb a1=0
a2=f71a60 a3=f71a58 items=1 ppid=9014 pid=9492 auid=root uid=root
gid=root euid=root suid=root fsuid=root egid=root sgid=root fsgid=root
tty=pts1 ses=8 comm=ausearch exe=/sbin/ausearch
subj=root:auditadm_r:auditadm_t:s0-s15:c0.c1023 key=(null) 
node=jcdx type=AVC msg=audit(02/27/2009 15:32:41.747:2986) : avc:
denied  { read } for  pid=9492 comm=ausearch name=audit.log dev=dm-0
ino=375 scontext=root:auditadm_r:auditadm_t:s0-s15:c0.c1023
tcontext=system_u:object_r:auditd_log_t:s15:c0.c1023 tclass=file 
node=jcdx type=AVC msg=audit(02/27/2009 15:32:41.747:2986) : avc:
denied  { search } for  pid=9492 comm=ausearch name=audit dev=dm-0
ino=33885 scontext=root:auditadm_r:auditadm_t:s0-s15:c0.c1023
tcontext=system_u:object_r:auditd_log_t:s15:c0.c1023 tclass=dir 

And the corresponding raw file has this:
...
node=jcdx type=AVC msg=audit(1235770361.747:2986): avc:  denied
{ search } for  pid=9492 comm="ausearch" name="audit" dev=dm-0 ino=33885
scontext=root:auditadm_r:auditadm_t:s0-s15:c0.c1023
tcontext=system_u:object_r:auditd_log_t:s15:c0.c1023 tclass=dir
node=jcdx type=AVC msg=audit(1235770361.747:2986): avc:  denied
{ read } for  pid=9492 comm="ausearch" name="audit.log" dev=dm-0 ino=375
scontext=root:auditadm_r:auditadm_t:s0-s15:c0.c1023
tcontext=system_u:object_r:auditd_log_t:s15:c0.c1023 tclass=file
node=jcdx type=SYSCALL msg=audit(1235770361.747:2986): arch=c000003e
syscall=2 success=yes exit=4 a0=7fffe635efeb a1=0 a2=f71a60 a3=f71a58
items=1 ppid=9014 pid=9492 auid=0 uid=0 gid=0 euid=0 suid=0 fsuid=0
egid=0 sgid=0 fsgid=0 tty=pts1 ses=8 comm="ausearch"
exe="/sbin/ausearch" subj=root:auditadm_r:auditadm_t:s0-s15:c0.c1023
key=(null)
node=jcdx type=CWD msg=audit(1235770361.747:2986):  cwd="/root"
node=jcdx type=PATH msg=audit(1235770361.747:2986): item=0
name="/var/log/audit/audit.log" inode=375 dev=fd:00 mode=0100600 ouid=0
ogid=0 rdev=00:00 obj=system_u:object_r:auditd_log_t:s15:c0.c1023

And what you are saying is that rather than use the ausearch equivalent
(or whatever tool which uses auparse library) on the receiving end, it
is more expedient to combine the record into one event prior to sending?
IIUC, is it because of the reduced amount of data flowing or less
processing needed on the receiving end (or both)?

Thx,
LCB.

-- 
LC (Lenny) Bruzenak
lenny@magitekltd.com

  parent reply	other threads:[~2009-02-27 22:12 UTC|newest]

Thread overview: 6+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2009-02-27 21:21 A combined audit event message Matthew Booth
2009-02-27 21:28 ` Steve Grubb
2009-02-27 21:32   ` Matthew Booth
2009-02-27 21:51   ` Matthew Booth
2009-02-27 22:12 ` LC Bruzenak [this message]
2009-02-27 22:27   ` Matthew Booth

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=1235772755.7212.50.camel@homeserver \
    --to=lenny@magitekltd.com \
    --cc=linux-audit@redhat.com \
    --cc=mbooth@redhat.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox