Quick and Dirty OpenBSM Auditing In macOS

OpenBSM is a subsystem that has been installed on the Mac for some time. OpenBSM provides that ability to create and read audit logs based on the Common Criteria standards.

Audit Logs

The quick and easy way to see what OpenBSM is auditing is to cat the /etc/security/audit_control file:

cat /etc/security/audit_control

The output displays the directory of audit logs, as well as what is currently being audited. By default the configuration is as follows:

#
# $P4: //depot/projects/trustedbsd/openbsm/etc/audit_control#8 $
#
dir:/var/audit
flags:lo,aa
minfree:5
naflags:lo,aa
policy:cnt,argv
filesz:2M
expire-after:10M
superuser-set-sflags-mask:has_authenticated,has_console_access
superuser-clear-sflags-mask:has_authenticated,has_console_access
member-set-sflags-mask:
member-clear-sflags-mask:has_authenticated

You can then see all of the files in your audit log, using a standard ls of those 

ls /var/audit

As you can see, the files are then stored with a date/time stamp naming convention. 

20180119012009.crash_recovery 20180407065646.20180407065716 20180407073931.20180407074018
20180119022233.crash_recovery 20180407065716.20180407065747 20180407074018.20180407074050
20180119043338.crash_recovery 20180407065747.20180407065822 20180407074050.20180511030725
20180119134354.crash_recovery 20180407065822.20180407065853 20180511030725.crash_recovery
20180208172535.crash_recovery 20180407065853.20180407065928 20180616025641.crash_recovery
20180219133137.crash_recovery 20180407065928.20180407070004 20180624022028.crash_recovery
20180312153634.crash_recovery 20180407070004.20180407070036 20180718235941.crash_recovery
20180312160131.crash_recovery 20180407070036.20180407071722 20180720031150.crash_recovery
20180322141701.crash_recovery 20180407071722.20180407072215 20180724021901.crash_recovery
20180330190040.crash_recovery 20180407072215.20180407072259 20180728173033.crash_recovery
20180330191420.20180407064622 20180407072259.20180407073747 20180907031058.crash_recovery
20180407064622.20180407065616 20180407073747.20180407073836 20180911021141.not_terminated
20180407065616.20180407065646 20180407073836.20180407073931 current

The files are binary and so cannot be read properly without the use of a tool to interpret the output. In the next section we will review how to read the logs. 

Using praudit

Binary files aren’t easy to read. Using the praudit binary, you can dump audit logs into XML using the -x flag followed by the path of the log. For example, the following command would read a given log in the above /var/audit example directory:

praudit -x 20180407065747.20180407065822

One record of the output would look as follows

<record version="11" event="session start" modifier="0" time="Sat Apr 7 01:58:22 2018" msec=" + 28 msec" >
<argument arg-num="1" value="0x0" desc="sflags" />
<argument arg-num="2" value="0x0" desc="am_success" />
<argument arg-num="3" value="0x0" desc="am_failure" />
<subject audit-uid="-1" uid="root" gid="wheel" ruid="root" rgid="wheel" pid="0" sid="100645" tid="0 0.0.0.0" />
<return errval="success" retval="0" />
</record>

In the above output, you’ll find the time that an event was logged, as well as the type of event. This could be parsed for specific events, and, as an example, just dump the time and event in a simple json or xml for tracking in another tool. For example, if you’re doing statistical analysis for how many times privileges were escalated as a means of detecting a bad actor on a system.

You can also use the auditreduce command to filter records. Once filtered, results are still in binary and must be converted using praudit.