Creating Privacy Preferences Policy Control profiles for macOS

As part of the pre-release announcements about macOS Mojave, Apple released the following KBase article:

Prepare your institution for iOS 12 or macOS Mojave:

https://support.apple.com/HT209028

As part of the KBase article, Apple included a Changes introduced in macOS Mojave section which featured this note:

You can allow apps to access certain files used for system administration, and to allow access to application data. For example, if an app requests access to your Calendar data, you can allow or deny the request. MDM administrators can manage these requests using the Privacy Preferences Policy Control payload, as documented in the Configuration Profile Reference.

What’s all this mean? For more details, see below the jump.

As part of macOS Mojave, Apple introduced new controls for accessing data in the individual user home folders. For more details about these changes, I recommend that you check out the following video and blog posts. Don’t worry about me, I’ll wait:

• Better Apps through Better Privacy: https://developer.apple.com/videos/play/wwdc2018/718/
• Apple Events Usage Description: https://indiestack.com/2018/08/apple-events-usage-description/
• macOS Mojave gets new APIs around AppleEvent sandboxing – but AEpocalyse still looms: https://www.felix-schwarz.org/blog/2018/08/new-apple-event-apis-in-macos-mojave
• A Looming Mac Automation Apocalypse?: https://sixcolors.com/link/2018/08/a-looping-mac-automation-apocalypse/

Back? OK, now that you’re familiar with what Apple was talking about with that section of the KBase, let’s discuss this section:

MDM administrators can manage these requests using the Privacy Preferences Policy Control payload, as documented in the Configuration Profile Reference.

What this means is that you may be able to whitelist your most common interactions and prevent them from displaying dialogs. Unfortunately, as of this date, Apple has provided only the following as documentation:

https://developer.apple.com/enterprise/documentation/Configuration-Profile-Reference.pdf (see the Privacy Preferences Policy Control Payload section.)

Apple refers to these as Privacy Preferences Policy Control Payload profiles, with a com.apple.TCC.configuration-profile-policy payload type. TCC stands for transparency consent and control and was discussed as part of the How iOS Security Really Works session at WWDC 2016:

https://developer.apple.com/videos/play/wwdc2016/705/?time=674

These profiles can only be deployed to macOS Mojave and must be deployed by an user-approved MDM solution.

While the current documentation doesn’t provide a lot of detail, based on my research, here is how the whitelist appears to work:

1. The item being whitelisted must be code-signed

As part of the profile, there is an entry for code signature so that the OS can verify that the whitelist entry matches up against the app requesting the action. How do you find out what the code signature of a particular app is? Run the following command against the application or other item that you want to whitelist:

codesign -dr - /path/to/Application.app

That said, there’s two ways that you can do this for third-party applications. As an example, if you’re using Jamf Pro 10.x to manage your Macs, the following application should be installed on your Mac:

/Library/Application Support/JAMF/Jamf.app

If you run the following command, you should get the code signature for the app:

codesign -dr - "/Library/Application Support/JAMF/Jamf.app"

	computername:~ username$ codesign -dr – "/Library/Application Support/JAMF/Jamf.app"
	Executable=/Library/Application Support/JAMF/Jamf.app/Contents/MacOS/Jamf
	designated => identifier "com.jamf.management.Jamf" and anchor apple generic and certificate 1[field.1.2.840.113635.100.6.2.6] /* exists */ and certificate leaf[field.1.2.840.113635.100.6.1.13] /* exists */ and certificate leaf[subject.OU] = "483DWKW443"
	computername:~ username$

view raw

gistfile1.txt

hosted with ❤ by GitHub

There’s two ways you can add this information to the profile:

Example A:

identifier "com.jamf.management.Jamf" and anchor apple generic

Example B:

identifier "com.jamf.management.Jamf" and anchor apple generic and certificate 1[field.1.2.840.113635.100.6.2.6] /* exists */ and certificate leaf[field.1.2.840.113635.100.6.1.13] /* exists */ and certificate leaf[subject.OU] = "483DWKW443"

Example A should be considered the least secure as it is very generic in how it reads the code signature, while Example B is the most secure because the full code signature is specified.

However, if Jamf ever needed to fundamentally change the code signature it was using for Jamf.app, Example A’s code signature would continue to match while Example B’s would not. Code signature fundamentals don’t change that often, but it is something to be aware of when creating the profiles.

One other thing to watch out for is multiple lines being returned by the code signature check, as I ran into this when checking an application produced by McAfee.

codesign -dr - "/Library/Application Support/McAfee/MSS/Applications/Menulet.app"

	computername:~ username$ codesign -dr – "/Library/Application Support/McAfee/MSS/Applications/Menulet.app"
	Executable=/Library/Application Support/McAfee/MSS/Applications/Menulet.app/Contents/MacOS/Menulet
	designated => identifier "com.yourcompany.Menulet" and anchor apple generic and certificate 1[field.1.2.840.113635.100.6.2.6] /* exists */ and certificate leaf[field.1.2.840.113635.100.6.1.13] /* exists */ and certificate leaf[subject.OU] = GT8P3H7SPW
	library => identifier libfmphelpers and anchor apple generic and certificate 1[field.1.2.840.113635.100.6.2.6] /* exists */ and certificate leaf[field.1.2.840.113635.100.6.1.13] /* exists */ and certificate leaf[subject.OU] = GT8P3H7SPW
	computername:~ username$

view raw

gistfile1.txt

hosted with ❤ by GitHub

The needed code signing is what’s listed on the designated => line of output:

identifier "com.yourcompany.Menulet" and anchor apple generic and certificate 1[field.1.2.840.113635.100.6.2.6] /* exists */ and certificate leaf[field.1.2.840.113635.100.6.1.13] /* exists */ and certificate leaf[subject.OU] = GT8P3H7SPW

2. The whitelist covers the parent process which is performing the action

Note: Here we’re heading off into territory that I can’t get confirmation about yet from Apple’s documentation. My research has lead me to the belief that the information below is right, but I don’t know for sure. Deploy appropriate levels of skepticism.

When creating the whitelist, you’re likely going to need to do a lot of testing to figure out what is actually calling an action that needs to be permitted by the user via a dialog window which appears. In many cases, you’ll need to whitelist the parent process which is asking for X, which in turn is running Y, which is executing Z and Z is what is actually causing the dialog window to appear.

A good example is when using Jamf’s Self Service to install software. A Self Service policy might include the following:

1. The policy which installs the software.
2. A notification that tells you “Hey, the software’s installed”
3. A script that pops up its own dialog window to say “Hey, we’ve installed this software but it’s unlicensed and we need you to now enter the license code you got from the help desk.”

Jamf has a couple of applications involved in this process to help it go smoothly:

/usr/local/jamf/bin/jamf
/usr/local/jamf/bin/jamfAgent

The notification and dialog window may trigger a dialog window which asks you if you want to allow a particular thing to happen. Depending on which application triggered it, you may see a notification that jamf (or jamfAgent) is the one requesting it. However, it may seem senseless: that “Hey, the software’s installed” notification is clearly an AppleScript dialog; why isn’t AppleScript the one being referred to as the requester?

The reason is that whichever application was named was the process that started the chain of events going. If jamfAgent is the one referenced, that means that the jamfAgent process is the process that asked AppleScript “Hey, mind showing that to my friend sitting between the keyboard and chair? Thanks.” So in this situation, even though it’s ultimately an AppleScript dialog window that appears, you would need to whitelist /usr/local/jamf/bin/jamfAgent.

3. There are filesystem permissions and there are application permissions

There are a number of dictionary keys available to the whitelist profiles:

• AddressBook
• Calendar
• Reminders
• Photos
• Camera
• Microphone
• Accessibility
• PostEvent
• SystemPolicyAllFiles
• SystemPolicySysAdminFiles
• AppleEvents

For whitelisting things like dialog messages and allowing access to data, there are two that seem to matter most:

• SystemPolicyAllFiles
• AppleEvents

SystemPolicyAllFiles allows the whitelisted application access to all protected files. As an example, your antivirus software may pop up dialog messages like crazy because it’s trying to scan areas of your home folder that Apple has now marked as protected. Once you identify the process which is actually running the scan and whitelist it using SystemPolicyAllFiles, the scans should now succeed without dialog messages because the scanning process has now been authorized by the whitelist to go into those areas.

AppleEvents allows the whitelisted application the ability to send an AppleEvent to an otherwise restricted application. For example, you may have a script which includes the following command:

osascript -e 'display dialog "Hey there!" with title "Hello"'

You may get a dialog window requesting permission to let osascript control the Finder. If you add an entry to your whitelist for /usr/bin/osascript, to authorize it to be able to send AppleEvents to com.apple.Finder, now you won’t get the permission request because now osascript is authorized to send requests to the Finder.

Creating the profiles

When creating my own profiles, I found a great tool created by Carl Ashley:

https://github.com/carlashley/tccprofile

This tool allowed me to plug in what I needed to whitelist and generated a profile for me. For example, I wanted to generate a profile for McAfee Endpoint Security with the following criteria:

Full Disk Access:

/Library/Application Support/McAfee/MSS/Applications/Menulet.app
/usr/local/McAfee/fmp/bin/fmpd

Note: /usr/local/McAfee/fmp/bin/fmpd is the McAfee file scanner

Able to send restricted AppleEvents:

/Library/Application Support/McAfee/MSS/Applications/Menulet.app – Send AppleEvents to SystemEvents, SystemUIServer and Finder

I was able to use the following command with the tccprofile tool to generate the profile I needed:

/path/to/tccprofile.py –allfiles "/Library/Application Support/McAfee/MSS/Applications/Menulet.app" /usr/local/McAfee/fmp/bin/fmpd –appleevents "/Library/Application Support/McAfee/MSS/Applications/Menulet.app","/System/Library/CoreServices/System Events.app" "/Library/Application Support/McAfee/MSS/Applications/Menulet.app","/System/Library/CoreServices/SystemUIServer.app" "/Library/Application Support/McAfee/MSS/Applications/Menulet.app","/System/Library/CoreServices/Finder.app" –allow –payload-description="This profile allows specified applications to display information to the logged-in user." –payload-identifier="com.company.mcafee.tcc.privacy.whitelist" –payload-name="Privacy Settings Whitelist – McAfee" –payload-org="Company Name" –payload-version="1" -o McAfee_All_Files_and_Notifications_v1.mobileconfig

view raw

gistfile1.txt

hosted with ❤ by GitHub

However, there was a problem with the profile because of McAfee’s extra code-signing line.

Once the profile was edited to remove the extra code signature information, the profile was ready to go.

Reference Examples

Since this is a new area for Mac admins, I’ve posted several profiles for reference at the following location:

https://github.com/rtrouton/privacy_preferences_control_profiles

All were generated by the tccprofile tool and I’ve included README files that describe the individual profiles and the commands used to create the profile in question.