BSM token format questions

[Ilmar S. Habibulin]

On Sun, 1 May 2005, Robert Watson wrote:

> (0) All Tokens
>
>  For all typed tokens, is it correct to use big endian (or network byte
>  order) conversion on little endian systems?
>
> (1) Arbitrary Data Token
>
>  The Sun web site file format documentation indictes there is a 1-byte
>  "how to print" token.  How should this value be interpreted?  Is any
>  treatment of byte order performed for the data?
Sun audit trails are incompatible across ultrasparc and i386 platforms.
So i think, that network byte order is ok for all cases, and for arbitrary
data also. As you can see in trustedos, i've used byte order convertion in
i386 like architectures, and you are using the same approach in openbsm.
Another thought -- this is an open source project, that can be integrated
in any other project, not even into unix like OS. So why no to propose own
documented standard, just need to take care it is solaris/sparc
compatible.

>
> (2) in_addr and in_addr_ex Tokens
>
>  The Sun web site documents in_addr as consisting of a 1 byte token ID, 1
>  byte address type ID, and 4 or 16 bytes of address data.  Is the address
>  type assumed to be the AF_xxx constant associated with that type on
>  Solaris?
My Trusted Solaris 8 doc says, that in_addr token consists of 1 byte token
ID (AU_IN_ADDR_TOKEN) and 4(16) bytes of IPv4 or IPv6 address. Maybe this
is an older version of audit trail.

>
>  The Sun web site documents in_addr_ex tokens as consisting of a 1 byte
>  token ID, 4 or 16 bytes of address type/length information, and 16 bytes
>  of address.
>
>  FWIW, the Darwin BSM library implementation uses both of these types
>  differently than is defined in the Sun docs.  It treats in_addr as a 1
>  byte token ID followed byt a 4-byte IPv4 address in network byte order,
>  and the in_add_ex token as a 1 byte token ID, a 4-byte address type
>  field (AF_xxx), followed by 4 bytes of IPv4 address, or 16 bytes of IPv6
>  address.  The implementation doesn't seem picky about byte order, but I
>  assume network byte order.
>
>  Questions: Is the assumption relating to type referring to the AF_xxx
>  constant correct?  Why can the address type/length field be 4 or 16
>  bytes, and how do you tell, in in_addr_ex?  Maybe there is a
>  documentation error?  Is it correct to use only network byte order for
>  the addresses?  How about the address type?
Why not to consult http://www.opensolaris.org source code, when it becomes
reachable?

> (3) ip Token
>
>  Is it correct to assume that the 20 bytes is an IP header, and that all
>  fields are stored in network byte order from the wire?
My doc says so.

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