BSM token format questions

[Andrew R. Reiter]

On Tue, 3 May 2005, Ilmar S. Habibulin wrote:

: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?

Any idea when it is supposed to be reachable? I've not heard about 
opensolaris.org, so am curious.

Thanks,
Andrew

:
:> (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
:
:

--
Andrew R. Reiter
arr at watson.org
arr at FreeBSD.org
To Unsubscribe: send mail to majordomo at trustedbsd.org
with "unsubscribe trustedbsd-discuss" in the body of the message