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/auditAs you can see, the files are then stored with a date/time stamp naming convention.
20180119012009.crash_recovery 20180407065646.20180407065716 20180407073931.2018040707401820180119022233.crash_recovery 20180407065716.20180407065747 20180407074018.2018040707405020180119043338.crash_recovery 20180407065747.20180407065822 20180407074050.2018051103072520180119134354.crash_recovery 20180407065822.20180407065853 20180511030725.crash_recovery20180208172535.crash_recovery 20180407065853.20180407065928 20180616025641.crash_recovery20180219133137.crash_recovery 20180407065928.20180407070004 20180624022028.crash_recovery20180312153634.crash_recovery 20180407070004.20180407070036 20180718235941.crash_recovery20180312160131.crash_recovery 20180407070036.20180407071722 20180720031150.crash_recovery20180322141701.crash_recovery 20180407071722.20180407072215 20180724021901.crash_recovery20180330190040.crash_recovery 20180407072215.20180407072259 20180728173033.crash_recovery20180330191420.20180407064622 20180407072259.20180407073747 20180907031058.crash_recovery20180407064622.20180407065616 20180407073747.20180407073836 20180911021141.not_terminated20180407065616.20180407065646 20180407073836.20180407073931 currentThe 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.20180407065822One 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.
