TrustedBSD Audit Project

[Robert Watson]

I've already pointed you at this, but for the benefits of the broader
list, I know of two past attempts to write audit code for FreeBSD.

The first was mine based on the POSIX.1e spec, back in the 3.0-CURRENT
days.  I still have a version of the patch on the FreeBSD/POSIX.1e
implementation page, but I have no expectation that the work is worth
reusing.  However, it explored letting the specification of the interface
drive the design of the kernel code.  I also looked a little at structure
memory management, a /dev/audit queue, auditd, etc.

The second was implemented by SRI, and was never formally released.  They
took a pretty different approach, relying on existing KTRACE kernel
functionality to drive the interception of pathname lookup (et al), and
planned to rely on userland code to map an optimized binary interface with
the kernel into something resembling the POSIX.1e audit spec.  I have
access to an early version of this code, under a BSD license, but it's
also from around the 3-CURRENT days.  Questions about it can probably be
directed at Nate Williams, who has since left SRI.

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.

I'm not really convinced as to what the best approach is for constructing
the in-kernel message, but I believe that avoiding complex memory
management and allocation is very important for performance reasons (as
well as to avoid starvation).  I suspect that using KTRACE as the basis
for the work is probably not the right approach, but the naming of file
system objects is a concern, including how to uniquely name objects
(absolute paths make things difficult for a variety of reasons).

Another problem you'll have to surmount is that BSD pulls in pathname
arguments on-demand in a number of places in the kernel, meaning that
potentially some arguments get pulled in in the system call
implementation, whereas others get pulled in deep in the VFS stack (during
mounting, for example). 

Finally, you'll probably want to e-mail John Baldwin <jhb at FreeBSD.org> to
discuss the changes he has in mind for the KTRACE mechanisms in kernel --
I believe he's moving to a model where a worker thread manages the KTRACE
message queue, in part for reasons of avoiding lock cycles, and similar
concerns may apply to an audit implementation. 

Robert N M Watson             FreeBSD Core Team, TrustedBSD Project
robert at fledge.watson.org      NAI Labs, Safeport Network Services

On Wed, 3 Oct 2001, Andrew R. Reiter wrote:

> 
> 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.
> 
>  - Design and Implement a possible alarm interface for alerting admins
>    to critical problems, which can include something like storage space
>    running out.
> 
>  - 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.
> 
>  - 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.
> 
> 
> 
> 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