A modular auditd

A modular auditd

[Matthew Booth]

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

Archiving audits daily

[Ed Christiansen]

Greetings,

I have a requirement to archive audits daily.  I can use the
audit tools to get all the records for a single day:

ausearch -ts 10/16/2008 00:00:00 -te 10/16/2008 23:59:60

but this returns a processed log entry.  I would like the
resulting event data to be in exactly the same format as the
original file instead so the ausearch and aureport tools
can be run directly on the resulting data file.  When I try
it with the ausearch data I get weird date results for the
start date.  I would have guessed at -u for unprocessed,
or -r for raw, but I don't see an option like this.  Is there
a way to accomplish this that I am missing?

Thanks in advance,
_____  ______________
\   / /__________   /
  | |  .  ...  .  | |    Ed Christiansen
  | | : ..   .. : | |    Group 93 ISSO/IT Team Lead
  | | .   ...   . | |
  | | : ..   .. : | |    MIT Lincoln Laboratory - Building S
  | |  ..  .  ..  | |    244 Wood St
  | | . ..   .. . | |    Lexington MA  02420-9185
  | | :.  ...  .: | |
  | | . ..  ..  . | |
  | |  .  ...  .  | |
  | |___________  | |
/_____________/ /___\

Re: Archiving audits daily

[Steve Grubb]

On Saturday 18 October 2008 10:58:19 Ed Christiansen wrote:
> I have a requirement to archive audits daily.  I can use the
> audit tools to get all the records for a single day:
>
> ausearch -ts 10/16/2008 00:00:00 -te 10/16/2008 23:59:60
>
> but this returns a processed log entry.

Add "--raw" to the ausearch line and you will get unprocessed lines.

-Steve