Re: Decoding BSM audit trail

Steve Smaha (Smaha@DOCKMASTER.NCSC.MIL)
Mon, 9 Oct 95 17:35 EDT 

RE:
    Date:  9 October 1995 00:00 edt
    From:  amo at INFO.FUNDP.AC.BE (Aziz MOUNJI)
    Subject:  Decoding BSM audit trail

    Hi all,

              I want to convert the BSM audit trail format to ASAX private
              format (NADF). I looked at the system documents but just can't
              bring myself to understand them. I looked at man audit.log
              but there, they speak of tokens in an audit record. What I
              wanted to know is *how* audit records are built from these tokens.
              More precisely, are tokens simply contiguous, or is there some
              padding bytes to ensure alignment, or is there a structure
              declaration for an entire audit record, ... ???
You mean you haven't done a massive hex/ascii dump yet ;)?  We've done 
analyzers for over a dozen audit trails, and invariably end up doing that.
This is not a joke.  (And it certainly wouldn't make people with fetishes
for "portable code" very happy to see real examples of code that isn't!)
There are no audit trails that are laid out exactly the way they are 
documented.

There's a structure defined for the entire audit file (file tokens
at the start/end of each file, plus header/trailer tokens for each
event).  Tokens are contiguous for records within the file.

Sun has even managed to make this work across Sparc and Intel byte
architectures!  (But you'll need to use their macros, or reverse
engineer them, to get the byte ordering stuff right.  Maybe that level
of interest is reserved for us commercial vendors.)  As implemented,
this is by far the best Unix audit trail, but power and completeness
come at a price.  The things it offers - full absolute pathnames, 
information about file owner and access rights for each object,
etc. - are not matched by any other vendor.

You'll need to get the BSM manuals.  The man pages won't suffice.

              The only conclusion I have at the time is that there is only
              a notion of tokens and it up to the application to figure out
              the sequencE of tokens comprising an audit record.
Yup.  It's well-defined in the context of the manual.  Note that not all
the events defined in the manual were implemented in the OS, and not
all the events implemented in the OS were documented in the manual.

If you look in Haystack Labs' email responder, there's a (very old)
body of ANSI C code that is a reference implementation of a
converter from SunOS BSM (virtually identical to Solaris BSM) to
Haystack Labs' svr4++ format.  I think that code will save you 
a LOT of time.

I think the file you'll want is called svr4prep.uue.  Send email to
info@haystack.com for how to get it.

Steve Smaha

Haystack Labs, Inc., 10713 RR 620N, Suite 521, Austin, TX 78726
512-918-3555 (voice), 512-918-1265 (fax), smaha@dockmaster.ncsc.mil

-- 
+---------------------+--------------------------------------------------+
|  ____       ___     | Justin Lister                 ruf@cs.uow.edu.au  |
| |    \\   /\ __\    |     Center for Computer Security Research        |
| | |) / \_/ / |_     | Dept. Computer Science      voice: 61-42-214-330 |
| |  _ \\   /| _/     | University of Wollongong      fax: 61-42-214-329 |
| |_/ \/ \_/ |_| (tm) |     Computer Security a utopian dream...         |
|                     |  LiNuX - the only justification for using iNTeL  |
+---------------------+--------------------------------------------------+