TrustedBSD Audit Project

[richard offer]

* frm arr at watson.org "10/03/2001 04:29:59 PM -0400" | sed '1,$s/^/* /'
*
* 
* TrustedBSD Audit Project
* ------------------------
* 
* Introduction
* 
* The purpose of this project is to design and implement the audit system
* for TrustedBSD.  This document is meant to describe the thoughts and goals
* behind the project and provide a basis for the design document.  The
* design document will the guideline for the implementation and hopefully
* we can all get it ready within the next couple of weeks, or however long
* deemed necesary by possible mailing list discussions.  Discussions have
* been taking place  between Logan Gabriel, Andrew Reiter, Robert Watson,
* and Stephanie Wehner  and we felt it was best to move the conversations
* and design talk to an  open forum.  We encourage all to help in this
* process.
* 
* 
* Thoughts & Goals List
* ---------------------
* 
*  - Develop functional, standards adhering, and optimized audit system
*    for TrustedBSD.
* 
*  - Adhere to Posix.1e specification which defines an interface to a 
*    trusted audit system.  
*    - We should deviate and/or expand upon the specification where it is
*      deemed by all to be necesary or uniquely helpful.

Extensions are almost neccessary (we have some), changes to base APIs are
less forgiving, particularly as the applications that will need audit
support are more than likely cross-platform.

Perhaps we need some way to distinguish between multiple audit
impletmentations, to allow for differences in names ? 

/* echo "TrustedBSD" | md5sum | cut -c -8 */
#define AUDIT_VENDOR 0xc4031fb3 ?

Since we will probably have the same header file (/usr/include/sys/audit.h)

* 
*  - Design and Implement a possible alarm interface for alerting admins
*    to critical problems, which can include something like storage space
*    running out.

For an evaluatable configuration, there are requirements for such thing as
running out of space. But setting high water marks prior to that sounds
good.

This should be a simple matter of programming for the daemon.

* 
*  - Research and possibly develop a new local filestore and local
* filesystem    pair for the sole purposes of holding audit records.  The
* goal is to     maximize use of storage space and create the ability for
* optimized     audit record lookups. 
*    - This includes topics like compression and format of the record on
* disk.

Audit records are just a stream of bytes, there should be no (or very
limited) wasted space. The on-disk format should be binary, so compression
has already been performed over the printable version of a record.

Compression is something for version 2. The first problem is to get enough
data flowing through the system that you are hitting the I/O limits of the
machine. We haven't found that to be the case with our implementation of
audit for Linux.

* 
*  - Research and implement remote logging capabilities.
* 
* This is meant to be an overview of the goals, but if you believe there is 
* something worth seriously looking at that is not mentioned here, please 
* email the list.
* 

richard.

-----------------------------------------------------------------------
Richard Offer                     Technical Lead, Trust Technology, SGI
"Specialization is for insects"
_______________________________________________________________________

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