TrustedBSD Audit Project

[Robert Watson]

On Mon, 8 Oct 2001, Gersh wrote:

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

It would be interesting to know what level of guarantee is required with
respects to the following concern:

(1) The event can only be allowed to take place if, baring certain
    classes of system failure, the record will be committed. 

(2) The event can only be allowed to take place once the record has been
    committed.

Presumably (1), or every system call would take a disk write.  (2) 
requires a reserved space for records, and tracking how much of the
reserved space has been theoretically allocated.  And you can imagine many
sites without "trusted system requirements" where the issue is not
committing the records to stable store, but rather, the ability for a
record processing system (such as IDS) to keep up with record generation.
Likewise, if audit log reduction is not taking place at the level of log
record generation (there isn't a commit protocol in place), the concerns
are different.

It sounds like the following approach might be reasonable:

- Large audit buffer in kernel, which if filled, requires audited
  processes to be blocked until it can be drained.  Note deadlock
  considerations here.  Probably also an administrative option to choose
  "lose data" instead of "halt audited processes" for sites where this is
  less of a consideration; make use of record sequence numbers so sites
  accepting record loss can detect loss, and permit a few simple loss
  policies ("lose oldest, lose newest" or the like)--you can imagine more
  complex policies being supported in the future.

- Userland process, which can notify the kernel if the free store for
  records approaches the size of the kernel buffer.  In practice this
  would consist of an invariant that the application wouldn't let the
  kernel buffer exceed the size of the free record storage.  The process
  could adapt the kernel record limit based on a variety of activities
  (reduction, compaction, recycling, compression..)

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

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