Unified Logs: How to Enable Private Data

The importance of Unified Logs

With each release of macOS more and more logs are migrated to the new database-style which means more and more information is subject to Apple’s privacy controls. With default settings unified logs are nearly useless for security purposes.

Up until very recently it was not easy to reveal data Apple marks as private at scale.

What is in the <private> fields of unified logs?

The data that is marked private in unified logs is typically the details about an action that could identify the user or computer. 

In most cases, enterprise software running on company-owned computers do not have these same privacy concerns. In fact, MDM tools have access to far more information about a user and computer than unified log private data would provide. 

In my opinion, unified logs private data is only private in the context of a personal use computer and not in the context of a company-owned machine used for work. I actually strongly agree with Apple’s default log privacy settings to help protect personal-use computers from unscrupulous personal data collection.

Example log data

# Here is what it looks like by default (hidden):
AuthenticationAllowed: Evaluation result for record "<private>", record type "<private>": Success

# And the same with private data enabled (shown)
AuthenticationAllowed: Evaluation result for record "dan", record type "users": Success

Testing plan

The most reliable way to test private data in logs is to trigger an authentication prompt.

My current favorite harmless way to trigger an authentication prompt is locking/unlocking the “Users and Groups” preference pane.

From terminal you can run the following to view authentication prompts

# This will show both failed and successful authentication attempts. 
# This is not the cleanest search for this info, but it works for this.
sudo log stream --predicate '(subsystem == "com.apple.opendirectoryd") && (senderImagePath == "\/System\/Library\/OpenDirectory\/Modules\/PlistFile.bundle\/Contents\/MacOS\/PlistFile")'

NOTE: Before deploying the profile

You will need to sign the profile before uploading to MDM tools like Jamf or Mosyle as they do not to my knowledge currently support this profile key.

If you upload an unsigned profile the MDM tool will change the profile in a way that breaks the private data settings.

The certificate that signs the configuration profiles is only important in that users could potentially see the name of the certificate that signed the profile.

How to sign a configuration profile

# Find profiles that can be used to sign in the keychain
/usr/bin/security find-identity -p codesigning -v
# Example output: 
# 22DC6A88856D5C082954D1F01H7EJ12FA4264E47 "Developer ID Application: cmdSecurity inc (26HM594V7Q)"

# Use one of the certificates listed like so to sign the profile
# I have used the example output above to fill in this example command
/usr/bin/security cms -S -Z "22DC6A88856D5C082954D1F01H7EJ12FA4264E47" -i "/Path/to/unsigned/profile.mobileconfig" -o "/output/path/for/new/signed/profile.mobileconfig"

Profile to enable (reveal) private data

<?xml version="1.0" encoding="UTF-8"?>
<!DOCTYPE plist PUBLIC "-//Apple//DTD PLIST 1.0//EN" "http://www.apple.com/DTDs/PropertyList-1.0.dtd">
<plist version="1.0">
      <string>ManagedClient logging</string>
  <string>Enable Unified Log Private Data logging</string>
  <string>Enable Unified Log Private Data</string>