BSM日志记录格式.docVIP

Audit Record Format A Solaris BSM audit record consists of a sequence of audit tokens, each of which describes an attribute of the system. Appendix?A, Audit Record Descriptions gives a detailed description of each audit token. The appendix also lists all the audit records generated by Solaris BSM auditing. The definitions are sorted in order of the short descriptions, and a cross-reference table translates event names to event descriptions. Binary Format Audit records are stored and manipulated in binary form; however, the byte order and size of data is predetermined to simplify compatibility between different machines. Audit Event Type Each auditable event in the system generates a particular type of audit record. The audit record for each event has certain tokens within the record that describe the event. An audit record does not describe the audit event class to which the event belongs; that mapping is determined by an external table, the /etc/security/audit_event file. Audit Token Types Each token starts with a one-byte token type, followed by one or more data elements in an order determined by the type. The different audit records are distinguished by event type and different sets of tokens within the record. Some tokens, such as the text token, contain only a single data element, while others, such as the process token, contain several (including the audit user ID, real user ID, and effective user ID). Order of Audit Tokens Each audit record begins with a header token and ends (optionally) with a trailer token. One or more tokens between the header and trailer describe the event. For user-level and kernel events, the tokens describe the process that performed the event, the objects on which it was performed, and the objects' tokens, such as the owner or mode. Each user-level and kernel event typically has at least the following tokens: header subject return Many events also include a trailer token, but it is optional. Human-Readable Audit Record Form