JFYI on my progress

[Robert Watson]

On Tue, 20 Apr 2004, Ilmar S. Habibulin wrote:

> I have implemented auditconfig(1M) utility from solaris. Plus some
> kernel hacks makes audit configuration flexible. When i finish auditd
> daemon i will post new patch agains recent current. 
> 
> My libbsm implementation differs from standard get* set* end* functions
> implementation approach. I read and parse all files at once using
> au_lib_init() function and storing all data in memory. Are trere any
> problems with my solution, why do other libraries use continious reads
> from files? 

The primary concern that comes to mind is audit log size: audit logs grow
rapidly, and rotated logs can easily exceed the memory of a system during
post-processing and analysis.  I think you want to be able to process logs
using a fixed memory bound even as file size grows.  Also, if you can
process audit records incrementally, you can use libbsm to process audit
record streams (i.e., over a socket, fifo, pipe, or pseudo-device) in real
time.

In earlier TrustedBSD audit work, I designed a plug-in for an auditd that
read records from /dev/audit (a different model from the current "kernel
writes to audit file); module plug-ins specified event record filters and
then were each fed records as they arrived to provide real-time
processing.  Modules could watch for specific events, take statistics,
etc.  While the model for a monitoring with modules will be different with
a BSM-centric API and reading from a file, I think we want to be able to
handle streams and sources that change size and grow.

Robert N M Watson             FreeBSD Core Team, TrustedBSD Projects
robert at fledge.watson.org      Senior Research Scientist, McAfee Research



To Unsubscribe: send mail to majordomo at trustedbsd.org
with "unsubscribe trustedbsd-audit" in the body of the message