Date: Sat, 15 Apr 2006 17:47:10 +0100 (BST) From: Robert Watson <rwatson@FreeBSD.org> To: trustedbsd-audit@TrustedBSD.org Subject: Audit pipe "interest" expression Message-ID: <20060415171927.T85663@fledge.watson.org>
next in thread | raw e-mail | index | archive | help
FreeBSD 7.x's audit pipe facility currently provides a direct pipe of audit record data as generated; the set of records received is limited by three factors: - Global audit selection settings in /etc/security. - Ability for the audit pipe reader to keep up with audit record flow (the queue is lossy). - The audit pipe reader providing sufficiently large buffers to hold complete audit records (a requirement which may change). This is quite useful, but raises a specific problem: if intrusion detection interests associated with audit pipe consumers don't align with global audit requirements, you either end up with insufficient information being fed to the intrusion detection application, or unnecessary information going into the global audit trail. The obvious solution is to allow audit pipe consumers to receive records selected using different criteria than the global trail. This would add an additional criteria to the above list: - The audit record has been selected based on per-pipe selection criteria. Then the obvious question becomes: what facility for criteria specification should the audit pipe facility provide? The global selection facility, in the style of Sun's BSM, allows selection of records based on audit identity, event class, and success/failure status of the event. Events are mapped to event classes in order to provide a level of indirection and avoid administrators from having to futz with individual event types, which are often opaque to everyone but application, and possibly system, developers. One possibility is to extend this facility to allow each audit pipe to specify its own independent criteria along the same lines: for example, allowing IDS tools to request mappings of {class mask, success/failure, audit ID} which will match events. This would rely on the existing globally defined classes, and have fairly minimal implementation requirements. Another more complex possibility is to allow audit pipes to each have their own mask context, or to allow pipe consumers to additionally specify direct event requirements. This would require significantly more state management and a more complex configuration mechanism. My leaning, for now, is to implement only the first. Record pre-selection points that currently exist would be enhanced to: - Examine audit pipe requirements in addition to current global requirements. - Tag accepted records with information on which consumer (trail, pipes, etc) had selected the record, so that the record is only delivered to requesting consumers. This raises an additional issue: drop behavior under overload. The existing audit trail facility will cause system stalls on overload, maintaining a maximum queue size for delivery to the file system. This maintains audit trail reliability in the presence of load. Intrusion detection consumers may not be interested in this behavior, and may prefer that records be dropped. The current audit pipe facility takes the approach of providing a fixed (but configurable) maximum queue depth for each pipe; when the pipe buffer is filled, new records are dropped. It has been suggested that allowing pipe consumers to specify priorities would permit a more informed drop decision: i.e., keep login/logout records in preference to stat() system calls. This makes a lot of sense for audit pipe consumers who track system events and maintain state associated with the running system -- for example, back-tracking socket communications to the executed command that lead to the communications. One possible approach here would be to extend the selection facility to allow priorities to be assigned to records, not just a simple boolean match. Comments on the above thoughts would be most welcome; I hope to spend some time working on adding an audit pipe selection facility in the next few weeks. In particular, I'd welcome information on intrusion detection consumers of audit data and their requirements -- confirmation that the lossy approach is good, thoughts on a precedence mechanism, and thoughts on what selection criteria are important to application writers. The current BSM selection mechanism is derived from the evaluation requirements of the Orange Book and CAPP. These don't necessarily match current real-world application requirements for IDS and monitoring, so advice along those lines would be great! I'd especially like to thank Martin Fong at SRI for his input and feedback relating to audit pipes, as his interest has driven current thinking about audit pipe selection facilities. Robert N M Watson
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20060415171927.T85663>