public inbox for linux-audit@redhat.com
 help / color / mirror / Atom feed
From: Matthew Booth <mbooth@redhat.com>
To: linux-audit@redhat.com
Subject: A modular auditd
Date: Wed, 15 Oct 2008 16:54:09 +0100	[thread overview]
Message-ID: <48F61221.2050509@redhat.com> (raw)

I was going over the reasons recently why I changed austream from being 
an auditd dispatcher to being a replacement audit daemon. They amounted to:

1. No nice way to prevent a dispatcher from generating audit events
2. Additional context switching becomes significant under load
3. Not possible to run auditd at real time priority
4. The config file is ugly if you don't want to write to disk

(1) is very bad, as it can cause a feedback loop which will eventually 
kill the machine. If you stare at it hard enough there are ways round 
it, but they're not pretty.

(2) When you really hammer it, the dispatcher interface overhead becomes 
significant. In addition to the context switching you're also losing 
message separation, so you need to do your own buffering.

(3) This is a problem if an application running at high priority 
generates a significant burst of audited events. No matter how big you 
make your buffers, if you produce faster than you consume you will 
eventually run out of space. In my testing the performance of the system 
when this happened was exceptionally poor (to the point of requiring a 
hard reset).

(4) is not a strong reason in itself, but it highlights that auditd was 
designed for writing to disk above all other use cases.

A while back I looked at Solaris's BSM, initially with a view to porting 
austream to Solaris. I noted that BSM has 'plugins' which are 
implemented as loadable modules[1]. It occurs to me that if auditd had 
the same, this would address points (1) and (2). (3) also becomes 
simpler and more robust once implemented, because you only have a single 
real time process.

Point (4) can be addressed by refactoring existing output methods into 
plugins. I believe this would currently amount to a 'file' plugin and a 
'dispatcher' plugin. If they aren't loaded, they wouldn't need to be 
unconfigured.

Thoughts?

Matt

[1] See man audit_control(4) and audit_syslog(5) on a Solaris system.
-- 
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

             reply	other threads:[~2008-10-15 17:38 UTC|newest]

Thread overview: 3+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2008-10-15 15:54 Matthew Booth [this message]
2008-10-18 14:58 ` Archiving audits daily Ed Christiansen
2008-10-18 15:28   ` Steve Grubb

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=48F61221.2050509@redhat.com \
    --to=mbooth@redhat.com \
    --cc=linux-audit@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