AUDIT_USER(5)

💅 AUDIT_USER(5) — the file formats manual page, bestie edition ✨

okay so this is the audit_user(5) page. it lives in the File Formats Manual section and it's literally all about telling your system which audit event classes to record for which users. no cap, it's a whole vibe. 🎀

---

🌸 NAME 🌸

audit_user — events to be audited for given users

---

✨ DESCRIPTION ✨

The audit_user file is the guest list that says which audit event classes get audited for the given users. 🫶 If you specify stuff here, these flags get combined with the system-wide audit flags in the audit_control(5) file to figure out which classes of events to audit for that user. and the way these settings take effect? only when the user logs in. so log out and back in, iykyk. 💅

Each line maps a user name to a list of classes that should be audited and a list of classes that should not be audited. the entries are giving this format:

username:alwaysaudit:neveraudit

In that format up there, alwaysaudit is a set of event classes that are always audited, and neveraudit is a set of event classes that should not be audited. these sets can indicate the inclusion or exclusion of multiple classes, and whether to audit successful or failed events. for more info about audit flags, go check audit_control(5). 👑

Example entries in this file are:

root:lo,ad:no
jdoe:-fc,ad:+fw

so these settings would cause login/logout and administrative events that are performed on behalf of user “root” to be audited. no failure events are audited. (root said "no failures, we don't do that here" 💀) For the user “jdoe”, failed file creation events are audited, administrative events are audited, and successful file write events are never audited. iconic behaviour tbh. ✨

---

🦋 IMPLEMENTATION NOTES 🦋

Per-user and global audit preselection configuration are evaluated at the time of login, so users must log out and back in again for audit changes relating to preselection to take effect. no shortcuts, bestie. 😭

Audit record preselection occurs with respect to the audit identifier associated with a process, rather than with respect to the UNIX user or group ID. The audit identifier is set as part of the user credential context as part of login, and typically does not change as a result of running setuid or setgid applications, such as su(1). This has the advantage that events that occur after running su(1) can be audited to the original authenticated user, as required by CAPP — but it may be surprising if not expected. 🙈 lowkey a plot twist, highkey intentional.

---

🍓 FILES 🍓

• /etc/security/audit_user

---

🌈 SEE ALSO 🌈

login(1), su(1), audit(4), audit_class(5), audit_control(5), audit_event(5)

---

💜 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. a whole origin story, honestly. ⭐

---

👑 AUTHORS 👑

This software was created by McAfee Research, the security research division of McAfee, Inc., under contract to Apple Computer Inc. Additional authors include Wayne Salamon, Robert Watson, and SPARTA Inc.

The Basic Security Module (BSM) interface to audit records and audit event stream format were defined by Sun Microsystems. 🧚

---

and that's the page, bestie!! this dropped from Debian on January 4, 2008 — oldie but a goodie, fr fr. go forth and audit responsibly 💖✨🎀