TrustedBSD Audit Project

[Gersh]

 From the mail that richard had sent out I rember a section saying
something like.

"The audit record has to be stored, or else the event cannot take
place".  I would assume that this means we have to be able to write the
record to disk before the action can be allowde to take place.  

Im not sure what kind of performence impacts this will have.

On Mon, 8 Oct 2001, Stephanie Wehner wrote:

> 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
> 

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