Audit subsystem beginnings.

[Andrew Reiter]

After contemplating re-writing the audit implementation that's for FreeBSD
2.x (I believe), I thought it would be better to possibly start off on
another foot.  Since there is a great deal of renewed interest in adding
trusted extensions to FreeBSD 4.0, I feel I should use this momentum for
what it's worth.

There are a couple things I feel that are worthy of a small discussion so
that we may come to a common agreement on how the task of doing the audit
subsystem should be tackled.

-[1] We must decide what is currently considered to be audit-like in the
current (4.0) implementation.  We must decide this so that we may not have
to always be reinventing the wheel.  If we feel that something is
audit-like, then we may be able to take this and easily rip it from the
current code and put it into our new audit subsystem.

-[2] We must decide what it is we actually want to implement.  What secure
level are we going for?  Are we going for a secure level?  Are we just
trying to model after the posix.1e interface specification.  We must come
up with a plan for how we wish this subsystem to actually be implemented.

-[3] Create a user/interface to act as the auditor.  The auditor being the
person/way the flags are set on objects and on subjects for auditing them
and the events caused/received by them.  I would suggest separating this
from root.

-[4] Decide on a set of agreeable terms for auditing the auditor.  This is
useful to help us determine tampering of rules etc.


I feel if we begin this discussion, that implementation will not be far
behind it.

Andrew

---------------------------------------------------------
Andrew Reiter	                 <s467338 at gettysburg.edu> 
Computer Security Engineer     

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