TrustedBSD Audit Project

[Stephanie Wehner]

On Mon, Oct 08, 2001 at 04:25:17PM -0400, Robert Watson wrote:
> 
> My recommendation for an initial kernel implementation would be to use
> neither of these as a starting point (although certainly to reference
> them), and look at a simple message queuing design in kernel, a /dev/audit
> that provides atomic reads of the messages off the queue (with the ability
> to determine the storage required for the next read), and a library that
> maps that structure into a POSIX.1e interface.

There's one thing I was wondering about, when reading the B1 audit guide:
Does the system have to make any guarantees that audit information is
actually stored ? 

The guide mentions that no matter how audit trail overflow is handled, 
'there must be a way to archive all of the audit data'. Possible actions
in case the log data can't be written that are listed there even include 
include stuff like stopping etc. From what I read on oss.sgi.com this
seems to be the action trusted irix will take after the reserved emergency
space has been exceeded also. Assuming that this was not a requirement,
I suppose these things should be configurable ? I was also wondering if
it would be an option to only log 'critical' events, if space gets lower,
although I'm not sure how 'trusted' this is.

bye,
Stephanie
--<> _ at r4k.net <>-------<> HAL 2001 - http://www.hal2001.org <>---
#31 - Anime Law of Non-anthropomorphic Antagonism
All ugly, non-humanoid alien races are hostile, and usually 
hell-bent on destroying humanity for some obscure reason.
To Unsubscribe: send mail to majordomo at trustedbsd.org
with "unsubscribe trustedbsd-audit" in the body of the message