Date: Mon, 28 May 2007 09:13:57 +0100 (BST) From: Robert Watson <rwatson@FreeBSD.org> To: "M. Warner Losh" <imp@bsdimp.com> Cc: trustedbsd-audit@freebsd.org, karma@ez.pereslavl.ru, karma@freebsd.org, freebsd-hackers@freebsd.org, trustedbsd-discuss@freebsd.org, mail@maxlor.com Subject: Re: SoC: Distributed Audit Daemon project Message-ID: <20070528090910.X2234@fledge.watson.org> In-Reply-To: <20070526.021609.-1749708199.imp@bsdimp.com> References: <200705250322.22259.karma@FreeBSD.org> <200705252004.38092.mail@maxlor.com> <20070526.021609.-1749708199.imp@bsdimp.com>
next in thread | previous in thread | raw e-mail | index | archive | help
On Sat, 26 May 2007, M. Warner Losh wrote:
> In message: <200705252004.38092.mail@maxlor.com>
> Benjamin Lutz <mail@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
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20070528090910.X2234>