New User Data Protections in macOS 10.14 or Later

Technical Articles
Solution
Application
Content Type
Technical Documentation
Utilities & Services
ft:locale
en-US

On macOS 10.14 or later, access to some user application data will require user approval.

Users can pre-approve apps by adding them to the new "Full Disk Access" category in the System Preferences Security & Privacy pane (macOS 12 or earlier) or System Settings Privacy & Security pane (macOS 13 or later). By adding apps, the user pre-approves access to all of their private-sensitive data without prompting. Administrator credentials are required to complete this process in System Preferences.

Approvals can also be managed remotely via MDM with the new Privacy Preferences Policy Control payload on macOS 10.14 or later.

Implications for Users

On macOS 10.14 or later, apps attempting to access protected files and app data may prompt end users to "allow" or "deny". If the app developer added purpose strings to the Info.plist, explaining the reasons for the data access request, that will also be presented with the prompt.

Apps compiled with previous versions of Xcode may not display a usage description for the prompt.

Implications for Jamf Pro Administrators

Jamf Pro administrators should prepare for the following behaviors on macOS 10.14 or later:

  • Some policies executed via Terminal may display a prompt for users to either allow or deny "Terminal" to execute.

  • Some policies executed in the background by the Jamf binary may cause an error. These failures may inaccurately report as successful.

Privacy Preferences Policy Control Payload

Organizations can use mobile device management to remotely manage security preferences with Apple's new Privacy Preferences Policy Control payload on macOS 10.14 or later.

The Privacy Preferences Policy Control payload controls the following Privacy Service Dictionary Keys:

  • AddressBook

  • Calendar

  • Reminders

  • Photos

  • Camera

  • Microphone

  • Accessibility

  • PostEvent

  • SystemPolicyAllFiles

  • SystemPolicySysAdminFiles

  • AppleEvents

To allow or deny an app or binary to access one of the above Privacy Service Dictionary Keys, you can create a payload that includes the following:
Dictionary KeyDescription

Identifier

A unique identifying value for the app or service. Use a bundle ID for apps or an installation path of the binary.

Identifier Type

Must be either the bundle ID or file path depending on if it is an app bundle or the binary.

Code Requirement

A unique value based on the developer certificate used to sign the app or service. This value is obtained via the command codesign – display -r -

Static Code

Optional: If an app has already been set to Allow=True with the services shown using the /usr/bin/log but still causes prompts, it may require setting this value to true. If set to true, statically validates the code requirement of the app or service on-disk. If set to false, verifies the app in-memory while it is running.This is used only if the process invalidates its dynamic code signature. False is the default setting.

Allowed

Boolean: If set to true, access is granted. If set to false, access is denied. A false value overrides a previously set value by a user in System Preferences (macOS 12 or earlier) or System Settings (macOS 13 or later) .

Code Signature Requirements and Bundle Identifiers
Jamf Pro administrators creating a custom configuration profile must include the code signature requirement and bundle ID for an app to allow access to protected user data. You can get the code signature requirement and bundle identifier (if needed) by running the following codesign commands:
codesign -dr - /Applications/Application.ap
codesign -dr - /path/to/binary
See the following table for examples:
InputOutput
codesign -dr - /usr/local/bin/jamf

Executable=/usr/local/jamf/bin/jamf designated => identifier "com.jamfsoftware.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"

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"

Use the following as the code signature:

identifier "com.jamfsoftware.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"
Note: If the app developer changes their code signing certificate, the existing profile will be invalidated and will require a new profile with the new code signature.
Identification of Processes and Apps Attempting Data Access

To identify the app or binary you are attempting to allow data access, execute the following command:

/usr/bin/log stream --debug --predicate 'subsystem == "com.apple.TCC" AND eventMessage BEGINSWITH "AttributionChain"'
To view previously requested data access, execute the following command:
/usr/bin/log show --predicate 'subsystem == "com.apple.TCC"' | grep Prompting