SoC: Distributed Audit Daemon project

Robert Watson rwatson at FreeBSD.org
Mon May 28 08:13:58 UTC 2007


On Sat, 26 May 2007, M. Warner Losh wrote:

> In message: <200705252004.38092.mail at maxlor.com>
>            Benjamin Lutz <mail at maxlor.com> writes:
> : On Friday 25 May 2007 01:22:21 Alexey Mikhailov wrote:
> : > [...]
> : > 2. As I said before initial subject of this project was "Distributed
> : > audit daemon". But after some discussions we had decided that this
> : > project can be done in more general maner. We can perform distributed
> : > logging for any user-space app.
> : > [...]
> :
> : This sounds very similar to syslogd. Is it feasible to make dlogd a drop-in
> : replacement for syslogd, at least from a syslog-using-program point of view?
>
> I suspect that it is dealing with different data streams.  syslog is for 
> programs sending text voluntarily.  auditd is for pulling audit trails out 
> of the kernel for which the 'target' programs have no knowledge that the 
> audit trails are being generated, let alone anyway to prevent it.

To possibly clarify a few points:

(1) A distributed audit daemon wouldn't eliminate the need for local daemons
     that already manage log streams from various sources -- for example,
     syslogd for syslog, auditd for audit, Apache generating its own log files,
     etc.  The goal of the distributed audit/log daemon is to manage these log
     files once log sources (such as auditd) are done with their logs.

(2) One of the trickiest parts of the design will be the interaction between
     log sources and the audit daemon, so that log files can reliably change
     hands from being managed by the source to the distributed log tool.  In
     the event of a system crash/power loss/network partition/syslogd
     crash/etc, we still want the log file to be picked up and synchronized.
     Hence discussion of an explicit hand-off API rather than casually looking
     in the same directory and hoping we get it right.

(3) Unlikely syslogd's network logging support, the goal here is secure,
     reliable, batched delivery.  We've talked a bit about live audit record
     delivery for IDS, but up front what we actually want to do is push the
     same sorts of reliability guarantees already present for local trail
     management to the distributed case.  We are looking at pushing existing
     trail files over the network in a spooled way rather than shipping
     individual records as they are generated for this reason.

Robert N M Watson
Computer Laboratory
University of Cambridge


More information about the freebsd-hackers mailing list