Audit Dispatcher Design

[Valdis.Kletnieks at vt.edu]

On Thu, 08 Sep 2005 09:35:32 EDT, Steve Grubb said:

> What can you say about error handling other than it must be correct? auditd is
> not going away. It will be the method for reliable logging. audisp is going
> to be best effort at this point. For example, if you use remote logging
> should the machine stop if the network goes down? Should it queue them and
> transfer when the network is up? What if the queue fills to capacity? If the
> remote logger's disk is full, should all machines on the network go to admin
> mode? That'll be a bummer. I don't think we want to face all these issues and
> claim 100% guarantee at this point.

I can't speak for others, but I can certainly live with best-effort for audisp,
as long as I can still configure auditd so we guarantee it locks up if we can't
generate at least *one* reliable log.

How much can we do for reliable *detection* of failure on audisp's part? For
instance, use a TCP connection, and syslog or something if we see an
EWOULDBLOCK (I know, not perfect, as it won't actually trip until we've sent
at least a window's worth of data if the other end glorbles up - but probably
good enough for my needs, and as good as it gets without an explicit ACK)....
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 226 bytes
Desc: not available
URL: <http://listman.redhat.com/archives/linux-audit/attachments/20050908/5ccbad20/attachment.sig>