BSM token format questions

[Robert Watson]

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

> On Sun, 1 May 2005, Robert Watson wrote:
>
>>  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.

I think this is a reasonable perspective to look at it from; I'm in the 
throes of creating an audit.log.5 for OpenBSM that documents the format, 
but fairly early on I ran into the the above (and below) issues.  So I'll 
add the following sentence to audit.log.5:

   All defined multi-byte data types are stored in network byte order (Big
   Endian).

Another related question concerns byte order and APIs for constructing/ 
tearing down data types relating to the network.  In the case of APIs that 
involve IP addresses, I think there's a strong argument to be made that 
the caller should pass the IP address in network byte order, as other 
system API that use addresses also expect network byte order -- i.e., 
bind(), connect(), inet_aton(), etc.  How about port numbers, though?  I'm 
currently leaning towards network byte order, as that's how they'll be 
when extracted from socket addresses, for example...

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