AUDIT.LOG(5)

💖 AUDIT.LOG(5) — Basic Security Module (BSM) file format 💖

okay bestie, welcome to the AUDIT.LOG(5) page from the File Formats Manual — this is part 1, and we are keeping absolutely every byte, field, and little gremlin detail. no skimming, no vibes-based summary, just the real BSM file format tea. 💅

🌸 NAME 🌸

audit — Basic Security Module (BSM) file format

💖 DESCRIPTION 💖

The audit file format is based on Sun’s Basic Security Module (BSM) file format, a token-based record stream to represent system audit data. This file format is both flexible and extensible — able to describe a broad range of data types, and easily extended to describe new data types in a moderately backward and forward compatible way. iconic behavior, honestly. ✨

BSM token streams typically begin and end with a “file” token, which provides time stamp and file name information for the stream; when processing a BSM token stream from a stream as opposed to a single file source, file tokens may be seen at any point between ordinary records identifying when particular parts of the stream begin and end. All other tokens will appear in the context of a complete BSM audit record, which begins with a “header” token, and ends with a “trailer” token, which describe the audit record. Between these two tokens will appear a variety of data tokens, such as process information, file path names, IPC object information, MAC labels, socket information, and so on. the way the tokens are just living their lives in there 😭

The BSM file format defines specific token orders for each record event type; however, some variation may occur depending on the operating system in use, what system options, such as mandatory access control, are present.

This manual page documents the common token types and their binary format, and is intended for reference purposes only.

💡 Recommended, fr fr: application programmers should use the libbsm(3) interface to read and write tokens, rather than parsing or constructing records by hand. your hands are for typing cute code, not hand-parsing binary records, bestie. 🫶

---

🎀 File Token 🎀

The “file” token is used at the beginning and end of an audit log file to indicate when the audit log begins and ends. It includes a pathname so that, if concatenated together, original file boundaries are still observable, and gaps in the audit log can be identified. A “file” token can be created using au_to_file(3).

Field lineup (field — bytes — description):

• Token ID — 1 byte — Token ID
• Seconds — 4 bytes — File time stamp
• Microseconds — 4 bytes — File time stamp
• File name lengh — 2 bytes — File name of audit trail
• File pathname — N bytes + 1 NUL — File name of audit trail

(and yes, “lengh” is literally spelled that way in the field name — we preserve the lore 🫡)

🦋 Header Token 🦋

The “header” token is used to mark the beginning of a complete audit record, and includes the length of the total record in bytes, a version number for the record layout, the event type and subtype, and the time at which the event occurred. A 32-bit “header” token can be created using au_to_header32(3); a 64-bit “header” token can be created using au_to_header64(3).

Field lineup:

• Token ID — 1 byte — Token ID
• Record Byte Count — 4 bytes — Number of bytes in record
• Version Number — 2 bytes — Record version number
• Event Type — 2 bytes — Event type
• Event Modifier — 2 bytes — Event sub-type
• Seconds — 4/8 bytes — Record time stamp (32/64-bits)
• Nanoseconds — 4/8 bytes — Record time stamp (32/64-bits)

🌸 Expanded Header Token 🌸

The “expanded header” token is an expanded version of the “header” token, with the addition of a machine IPv4 or IPv6 address. A 32-bit extended “header” token can be created using au_to_header32_ex(3); a 64-bit extended “header” token can be created using au_to_header64_ex(3).

Field lineup:

• Token ID — 1 byte — Token ID
• Record Byte Count — 4 bytes — Number of bytes in record
• Version Number — 2 bytes — Record version number
• Event Type — 2 bytes — Event type
• Event Modifier — 2 bytes — Event sub-type
• Address Type/Length — 1 byte — Host address type and length
• Machine Address — 4/16 bytes — IPv4 or IPv6 address
• Seconds — 4/8 bytes — Record time stamp (32/64-bits)
• Nanoseconds — 4/8 bytes — Record time stamp (32/64-bits)

🎀 Trailer Token 🎀

The “trailer” terminates a BSM audit record, and contains a magic number, AUT_TRAILER_MAGIC and length that can be used to validate that the record was read properly. A “trailer” token can be created using au_to_trailer(3).

Field lineup:

• Token ID — 1 byte — Token ID
• Trailer Magic — 2 bytes — Trailer magic number
• Record Byte Count — 4 bytes — Number of bytes in record

✨ Arbitrary Data Token ✨

The “arbitrary data” token contains a byte stream of opaque (untyped) data. The size of the data is calculated as the size of each unit of data × the number of units of data. A “How to print” field is present to specify how to print the data, but interpretation of that field is not currently defined. An “arbitrary data” token can be created using au_to_data(3).

Field lineup:

• Token ID — 1 byte — Token ID
• How to Print — 1 byte — User-defined printing information
• Basic Unit — 1 byte — Size of a unit in bytes
• Unit Count — 1 byte — Number of units of data present
• Data Items — Variable — User data

🍓 in_addr Token 🍓

The “in_addr” token holds a network byte order IPv4 address. An “in_addr” token can be created using au_to_in_addr(3) for an IPv4 address.

Field lineup:

• Token ID — 1 byte — Token ID
• IP Address — 4 bytes — IPv4 address

🧚 Expanded in_addr Token 🧚

The “in_addr_ex” token holds a network byte order IPv4 or IPv6 address. An “in_addr_ex” token can be created using au_to_in_addr_ex(3) for an IPv6 address.

👀 Heads up: see the “BUGS” section for information on the storage of this token.

Field lineup:

• Token ID — 1 byte — Token ID
• IP Address Type — 1 byte — Type of address
• IP Address — 4/16 bytes — IPv4 or IPv6 address

⭐ ip Token ⭐

The “ip” token contains an IP packet header in network byte order. An “ip” token can be created using au_to_ip(3).

Field lineup:

• Token ID — 1 byte — Token ID
• Version and IHL — 1 byte — Version and IP header length
• Type of Service — 1 byte — IP TOS field
• Length — 2 bytes — IP packet length in network byte order
• ID — 2 bytes — IP header ID for reassembly
• Offset — 2 bytes — IP fragment offset and flags, network byte order
• TTL — 1 byte — IP Time-to-Live
• Protocol — 1 byte — IP protocol number
• Checksum — 2 bytes — IP header checksum, network byte order
• Source Address — 4 bytes — IPv4 source address
• Destination Address — 4 bytes — IPv4 destination address

💜 iport Token 💜

The “iport” token stores an IP port number in network byte order. An “iport” token can be created using au_to_iport(3).

Field lineup:

• Token ID — 1 byte — Token ID
• Port Number — 2 bytes — Port number in network byte order

🎀 Path Token 🎀

The “path” token contains a pathname. A “path” token can be created using au_to_path(3).

Field lineup:

• Token ID — 1 byte — Token ID
• Path Length — 2 bytes — Length of path in bytes
• Path — N bytes + 1 NUL — Path name

🦋 path_attr Token 🦋

The “path_attr” token contains a set of NUL-terminated path names. The libbsm(3) API cannot currently create a “path_attr” token.

• Token ID — 1 byte — Token ID
• Count — 2 bytes — Number of NUL-terminated string(s) in token
• Path — Variable — count NUL-terminated string(s)

🫶 Process Token

okay so the “process” token is literally the security-properties glow-up of a process that's the target of an auditable event — like the destination when a signal gets delivered. Don't confuse it with the “subject” token, bestie — that one's the main character doing the auditable event, iykyk. This token includes the classic Unix security properties (user IDs and group IDs) plus audit info like audit user ID and session. You can create one with au_to_process32(3) or au_to_process64(3).

• Token ID — 1 byte — Token ID
• Audit ID — 4 bytes — Audit user ID
• Effective User ID — 4 bytes — Effective user ID
• Effective Group ID — 4 bytes — Effective group ID
• Real User ID — 4 bytes — Real user ID
• Real Group ID — 4 bytes — Real group ID
• Process ID — 4 bytes — Process ID
• Session ID — 4 bytes — Audit session ID
• Terminal Port ID — 4/8 bytes — Terminal port ID (32/64-bits)
• Terminal Machine Address — 4 bytes — IP address of machine

🦋 Expanded Process Token

The “expanded process” token has everything the “process” token has, plus a machine address type and variable-length address storage that's capable of holding IPv6 addresses. Create one with au_to_process32_ex(3) or au_to_process64_ex(3).

• Token ID — 1 byte — Token ID
• Audit ID — 4 bytes — Audit user ID
• Effective User ID — 4 bytes — Effective user ID
• Effective Group ID — 4 bytes — Effective group ID
• Real User ID — 4 bytes — Real user ID
• Real Group ID — 4 bytes — Real group ID
• Process ID — 4 bytes — Process ID
• Session ID — 4 bytes — Audit session ID
• Terminal Port ID — 4/8 bytes — Terminal port ID (32/64-bits)
• Terminal Address Type/Length — 1 byte — Length of machine address
• Terminal Machine Address — 4 bytes — IPv4 or IPv6 address of machine

🌸 Return Token

The “return” token is giving system call or library function return condition, including the return value and the error number associated with the global variable errno. Create one with au_to_return32(3) or au_to_return64(3).

• Token ID — 1 byte — Token ID
• Error Number — 1 byte — Errno value, or 0 if undefined
• Return Value — 4/8 bytes — Return value (32/64-bits)

🎀 Subject Token

The “subject” token contains info on the subject performing the operation described by an audit record, and it has similar info to the “process” and “expanded process” tokens. BUT — and this is the key part — those tokens are used when the process being described is the target of the operation, not the authorizing party. A “subject” token can be created using au_to_subject32(3) and au_to_subject64(3).

• Token ID — 1 byte — Token ID
• Audit ID — 4 bytes — Audit user ID
• Effective User ID — 4 bytes — Effective user ID
• Effective Group ID — 4 bytes — Effective group ID
• Real User ID — 4 bytes — Real user ID
• Real Group ID — 4 bytes — Real group ID
• Process ID — 4 bytes — Process ID
• Session ID — 4 bytes — Audit session ID
• Terminal Port ID — 4/8 bytes — Terminal port ID (32/64-bits)
• Terminal Machine Address — 4 bytes — IP address of machine

🧚 Expanded Subject Token

The “expanded subject” token has the same elements as the “subject” token, plus type/length and variable-size machine address info in the terminal ID. Create one with au_to_subject32_ex(3) or au_to_subject64_ex(3).

• Token ID — 1 byte — Token ID
• Audit ID — 4 bytes — Audit user ID
• Effective User ID — 4 bytes — Effective user ID
• Effective Group ID — 4 bytes — Effective group ID
• Real User ID — 4 bytes — Real user ID
• Real Group ID — 4 bytes — Real group ID
• Process ID — 4 bytes — Process ID
• Session ID — 4 bytes — Audit session ID
• Terminal Port ID — 4/8 bytes — Terminal port ID (32/64-bits)
• Terminal Address Type/Length — 1 byte — Length of machine address
• Terminal Machine Address — 4 bytes — IPv4 or IPv6 address of machine

🍓 System V IPC Token

The “System V IPC” token contains the System V IPC message handle, semaphore handle or shared memory handle. A System V IPC token may be created using au_to_ipc(3).

• Token ID — 1 byte — Token ID
• Object ID type — 1 byte — Object ID
• Object ID — 4 bytes — Object ID

✨ Text Token

The “text” token contains a single NUL-terminated text string. Create one with au_to_text(3).

• Token ID — 1 byte — Token ID
• Text Length — 2 bytes — Length of text string including NUL
• Text — N bytes + 1 NUL — Text string including NUL

💜 Attribute Token

The “attribute” token describes the attributes of a file associated with the audit event. Since files may be identified by 0, 1, or many path names, a path name is not included with the attribute block for a file; optional “path” tokens may also be present in an audit record indicating which path, if any, was used to reach the object. Create one with au_to_attr32(3) or au_to_attr64(3).

• Token ID — 1 byte — Token ID
• File Access Mode — 1 byte — mode_t associated with file
• Owner User ID — 4 bytes — uid_t associated with file
• Owner Group ID — 4 bytes — gid_t associated with file
• File System ID — 4 bytes — fsid_t associated with file
• File System Node ID — 8 bytes — ino_t associated with file
• Device — 4/8 bytes — Device major/minor number (32/64-bit)

🌈 Groups Token

The “groups” token contains a list of group IDs associated with the audit event. Create one with au_to_groups(3).

• Token ID — 1 byte — Token ID
• Number of Groups — 2 bytes — Number of groups in token
• Group List — N * 4 bytes — List of N group IDs

👑 System V IPC Permission Token

The “System V IPC permission” token contains System V IPC access permissions. A System V IPC permission token may be created using au_to_ipc_perm(3).

• Token ID — 1 byte — Token ID
• Owner user ID — 4 bytes — User ID of IPC owner
• Owner group ID — 4 bytes — Group ID of IPC owner
• Creator user ID — 4 bytes — User ID of IPC creator
• Creator group ID — 4 bytes — Group ID of IPC creator
• Access mode — 4 bytes — Access mode
• Sequnce number — 4 bytes — Sequnce number
• Key — 4 bytes — IPC key

Arg Token 🧾

okay so the “arg” token is all about the arguments of a system call. Depending on how big the desired argument value is, you can create an Arg token with au_to_arg32(3) or au_to_arg64(3). ✨

• Token ID — 1 byte — Token ID
• Argument ID — 1 byte — Argument ID
• Argument value — 4/8 bytes — Argument value
• Length — 2 bytes — Length of the text
• Text — N bytes + 1 nul — The string including nul

exec_args Token 🧾

The “exec_args” token holds info about the arguments of the exec() system call. You make one with au_to_exec_args(3). 🫶

• Token ID — 1 byte — Token ID
• Count — 4 bytes — Number of arguments
• Text — * bytes — Count nul-terminated strings

exec_env Token 🧾

The “exec_env” token contains the current environment variables to an exec() system call. And the page says an exec_args token may be created using au_to_exec_env(3) — yes, it literally says exec_args there, bestie, no cap. 🫠

• Token ID — 1 byte — Token ID
• Count ID — 4 bytes — Number of variables
• Text — * bytes — Count nul-terminated strings

Exit Token 🧾

The “exit” token has process exit/return code info. You can create one with au_to_exit(3). 💅

• Token ID — 1 byte — Token ID
• Status — 4 bytes — Process status on exit
• Return Value — 4 bytes — Process return value on exit

Socket Token 🧾

The “socket” token is all about UNIX domain and Internet sockets. Each token has four or eight fields. Depending on the type of socket, you create one with au_to_sock_unix(3), au_to_sock_inet32(3), or au_to_sock_inet128(3). 🔥

• Token ID — 1 byte — Token ID
• Socket family — 2 bytes — Socket family
• Local port — 2 bytes — Local port
• Socket address — 4 bytes — Socket address

Expanded Socket Token 🧾

The “expanded socket” token contains info about IPv4 and IPv6 sockets. A “expanded socket” token can be created using au_to_socket_ex(3). 🌈

• Token ID — 1 byte — Token ID
• Socket domain — 2 bytes — Socket domain
• Socket type — 2 bytes — Socket type
• Address type — 2 byte — Address type (IPv4/IPv6)
• Local port — 2 bytes — Local port
• Local IP address — 4/16 bytes — Local IP address
• Remote port — 2 bytes — Remote port
• Remote IP address — 4/16 bytes — Remote IP address

Seq Token 🧾

The “seq” token carries a unique and monotonically increasing audit event sequence ID. But listen: due to the limited range of 32 bits, use serial number arithmetic and caution when comparing sequence numbers. 🔥

• Token ID — 1 byte — Token ID
• Sequence Number — 4 bytes — Audit event sequence number

privilege Token 🧾

The “privilege” token ... and that's literally all the page gives us here, bestie. The table has a Token ID row and then just XXXXX. 🫠

• Token ID — 1 byte — Token ID
• XXXXX

Use-of-auth Token 🧾

The “use-of-auth” token ... same situation: Token ID and XXXXX, no cap. 🙈

• Token ID — 1 byte — Token ID
• XXXXX

Command Token 🧾

The “command” token ... again, Token ID and XXXXX. The mystery continues. 🕵️

• Token ID — 1 byte — Token ID
• XXXXX

ACL Token 🧾

The “ACL” token ... yep, Token ID and XXXXX. That's the whole vibe. 💅

• Token ID — 1 byte — Token ID
• XXXXX

Zonename Token 🧾

The “zonename” token holds a NUL-terminated string with the name of the zone or jail from which the record originated. You create one with au_to_zonename(3). 🦋

• Token ID — 1 byte — Token ID
• Zonename length — 2 bytes — Length of zonename string including NUL
• Zonename — N bytes + 1 NUL — Zonename string including NUL

---

✨ SEE ALSO ✨

• auditreduce(1)
• praudit(1)
• libbsm(3)
• audit(4)
• auditpipe(4)
• audit(8)

📜 HISTORY 📜

The OpenBSM implementation was created by McAfee Research — the security division of McAfee Inc. — under contract to Apple Computer Inc. in 2004. It was subsequently adopted by the TrustedBSD Project as the foundation for the OpenBSM distribution. 🌈

👑 AUTHORS 👑

The Basic Security Module (BSM) interface to audit records and audit event stream format were defined by Sun Microsystems. This manual page was written by Robert Watson <rwatson@FreeBSD.org>. 🫶

💀 BUGS 💀

The “How to print” field in the “arbitrary data” token has undefined values.

The “in_addr” and “in_addr_ex” token layout documented here appears to be in conflict with the libbsm(3) implementation of au_to_in_addr_ex(3).

---

And that's the whole page, bestie! This one comes from Debian, dated November 5, 2006, and it's the AUDIT.LOG(5) man page. Stay slay and audit responsibly! 💖✨🎀