September 24, 2018

Apple macOS Mojave User Consent for Data Access Changes, and VMware Workspace ONE UEM

The macOS Mojave 10.14.0 release introduces some updates to the Apple user-centric inter-app data-sharing security model. This updated security model for user consent for data access performs two basic functions. Any macOS device administrator wanting to ease their users’ transition to the new user consent for data access behavior in Mojave must pay close attention to the new Privacy Preferences Policy Control payload.

The macOS Mojave 10.14.0 release introduces some updates to the Apple user-centric inter-app data-sharing security model. This updated security model for user consent for data access performs two basic functions. First, it centralizes the control and restriction for apps that impersonate a user (and possibly make security decisions on their behalf). Second, it expands the locations for which a new attempt from a sandboxed macOS application to access data within another sandboxed app (or protected data or files) must first be allowed by the user or by Mobile Device Management (MDM). Any macOS device administrator wanting to ease their users’ transition to the new user consent for data access behavior in Mojave must pay close attention to the new Privacy Preferences Policy Control payload.

What Is User Consent for Data Access?

The concept of user consent has existed for years in the Apple OS ecosystem. At WWDC 2016, Apple discussed their design paradigm called transparency consent and control (TCC), which focused on obtaining a user's consent for access to private or protected data. TCC was part of the security mechanism where a sandboxed application must request the user’s permission to access data from another application or protected system resource. Your users are most likely familiar with this implementation for user consent from iOS, wherein an app requests location data (Figure 1) or some other type of access.

Figure 1: TCC Prompting User Consent for Protected Data

Within macOS, much of the functionality for user consent for data access was driven from the Privacy tab within the Security & Privacy preference pane (Figure 2). Within the Privacy preferences, the user had to select which apps were allowed access to protected data within macOS, such as Location Services, Contacts, Calendar, and so on.  Additionally, within the Privacy preferences the user could grant user interface (UI) automation using the Accessibility preferences (Figure 3). Even so, some UI elements rejected or overrode the user’s consent for automated UI control (such as the Profiles preference-pane prompt for user-approved MDM) and required manual button-clicks from the user.

Figure 2:  Security & Privacy Preference Pane Controls User Consent for Data Access in macOS
Figure 3:  Accessibility Preferences Control for UI Automation

What Is the Big Deal?

Apple continues to innovate on their goal of improving security within macOS.  As shown in Figure 4, macOS Mojave expands the apps and system data locations where the user must provide consent (even if the application is accessing the backing datastore directly on the file system). This means that apps that are not coded to handle these new prompts for user consent can appear hung while waiting for macOS to present the authorization prompt to the user.  Additionally, applications that access data from multiple locations (or the entire file system—for example, backup software) can trigger multiple authorization prompts, depending on the data being accessed.  

Figure 4:  macOS Mojave Expands TCC Scope with More Options

Late in the beta release cycle, Apple introduced the ability for MDM vendors to configure user consent for data access permissions on behalf of the user on a User-Approved MDM enrolled device. As documented in the recently updated Configuration Profile Reference, the Privacy Preferences Policy Control payload controls settings which the user would otherwise need to configure in the Privacy tab of the Security & Preferences pane. In the Privacy Preferences Policy Control payload, Apple allows pre-configuring the following services:

Key

Impact to Settings

AddressBook

Manages access to information managed by Contacts.app

Calendar

Manages access to information managed by Calendar.app

Reminders

Manages access to information managed by Reminders.app

Photos

Manages access to pictures managed by Photos.app in ~/Pictures/.photoslibrary

Camera

Manages a list of apps explicitly denied access to the system camera.  Access cannot be granted using this profile.

Microphone

Manages a list of apps explicitly denied access to the system microphone.  Access cannot be granted using this profile.

Accessibility

Manages which apps can control an application using the Accessibility subsystem

PostEvent

Manages which apps can send CoreGraphics events

SystemPolicyAllFiles

** USE CAREFULLY ** Grants applications access to all protected files. This is most likely the policy you would use for Data Backup applications.

SystemPolicySysAdminFiles

** USE CAREFULLY ** Grants applications access to files used in system administration.  This is most likely the policy you would need to grant your various management agents, such as the VMware AirWatch Agent or VMware Workspace ONE application.

AppleEvents

Manages access to inter-app or inter-process restricted events

 

As an administrator, you must note a few critical items. First, the Allowed key is documented as preventing the user from changing the value specified in the Privacy Preferences Policy Control payload. This means that whatever settings you configure via MDM cannot be overridden and modified by the user. Second, in our testing we found that any configurations we made via MDM were not displayed to the user in the Privacy Preferences pane. This means that a user or administrator would need to look at both the privacy preferences within the Security Preference panel and the privacy preference policy control profile in the Profiles preference panel to determine the full list of applied policies.

 

Note: As you begin your testing, you can easily identify user consent-related events in unified logging. Run the following command in Terminal.app: 

log stream --debug --predicate 'subsystem == "com.apple.TCC" AND eventMessage BEGINSWITH "AttributionChain"'

 

As you can see, there are now a number of new capabilities for managing user consent for data access in macOS Mojave’s Privacy Preferences Policy Control payload. It is critical that you begin testing your device management workflows and users’ applications immediately.  If you find any issues, submit feedback to the respective vendors about any apps that do not work as expected. Additionally, be proactive and contact your various software vendors to ensure they are actively testing compatibility with macOS Mojave. Finally, I encourage you to file Apple Radars with your developer account (or submit macOS product feedback) if you find any measurable impact to your business and need Apple to consider altering these upcoming changes to the Privacy Preferences Policy Control payload and how it impacts user consent for data access.

Testing Your Applications with Privacy Preferences Policy Control

As you begin testing, use the following table and command lines to better understand the profile’s keys and values:

Profile Key Description
Identifier The unique identifying value for the binary or service. For applications, specify the bundle ID. For supporting binaries, use the installation path.
Code Requirement

This is a unique string based upon the developer certificate which was used to sign the Identifier (binary or bundle ID). You can obtain this value by running the following command in Terminal.app:

 

codesign --display -r - /path/to/app/binary

Static Code Validation Some applications might intentionally make changes to themselves in memory. If you set Static Code Validation to True, macOS checks only the Code Requirement of the files on disk and not the application loaded in memory. Generally speaking, use this option as a last resort if you are absolutely sure the Code Requirement and Identifier are correct.

 

Some examples to how to derive the values of Identifier and Code Requirement are shown below. The Identifier and Code Requirement as highlighted in the command output:

 

  1. Quicktime Player.app
    1. Command Line:  codesign --display -r - /Applications/QuickTime\ Player.app/
    2. Command Output:  Executable=/Applications/QuickTime Player.app/Contents/MacOS/QuickTime Player designated => identifier "com.apple.QuickTimePlayerX" and anchor apple
    3. Identifier:  com.apple.QuickTimePlayerX
    4. Code Requirement:  identifier "com.apple.QuickTimePlayerX" and anchor apple
  2. VMware Fusion.app
    1. Command Line:  codesign --display -r - /Applications/VMware\ Fusion.app/
    2. Command Output:  Executable=/Applications/VMware Fusion.app/Contents/MacOS/VMware Fusion designated => identifier "com.vmware.fusion" 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] = EG7KH642X6
    3. Identifier:  com.vmware.fusion
    4. Code Requirement:  identifier "com.vmware.fusion" 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] = EG7KH642X6
  3. AirWatch Agent Daemon
    1. Command Line:   codesign --display -r - /Library/Application\ Support/AirWatch/airwatchd
    2. Command Output:  Executable=/Library/Application Support/AirWatch/airwatchd designated => anchor apple generic and identifier airwatchd and (certificate leaf[field.1.2.840.113635.100.6.1.9] /* exists */ or 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] = S2ZMFGQM93)
    3. Identifier:  /Library/Application Support/AirWatch/airwatchd

      Note:  While the command output notes the identifier as airwatchd, use the full path to the binary as the Identifier.
       

    4. Code Requirement:  anchor apple generic and identifier airwatchd and (certificate leaf[field.1.2.840.113635.100.6.1.9] /* exists */ or 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] = S2ZMFGQM93)

How Does User Consent for Data Access Affect VMware Workspace ONE UEM?

As you can expect, these changes will impact almost every macOS app developer, and particularly device management vendors. With regard to Workspace ONE UEM, we have currently found two specific impacts resulting from this new behavior.  

First, we are currently designing a user interface that allows administrators to build their Privacy Preferences Policy Control payload for macOS Mojave devices. Yes, the Configuration Profile Reference does lay out all the keys and values. However, we imagine it may be difficult for a device administrator new to MDM to understand the criticality of this payload and how to build it correctly.

Second, there are initially some impacts to the functionality of the VMware AirWatch Agent (Workspace ONE UEM Agent) for macOS. As shown in Figures 5 and 6, user consent for data access prompts the user to allow access for the agent (even though the prompts may not be sufficiently informative on the actions being taken). We will continue testing the impact to our agents and will provide corrections and guidance as appropriate.  

Figure 5:  TCC Settings Request User Consent to View Logs in Agent
Figure 6:  TCC Settings Request User Consent When Admin Runs Script Using Products Engine

Additional Resources

Apple device administrators need to ask their Apple sales representatives about gaining access to the Appleseed for IT program. This program provides members with earlier access to betas than what is provided to the general public. Members also get access to detailed release notes and testing guides.

If your organization has not completed testing with the betas, remember that you can optionally delay availability of the macOS Mojave upgrade until you can complete testing to determine impact. Note that devices running macOS High Sierra (10.13.4) and later can be prevented from seeing the available update by using the Delay Updates setting in the Security & Privacy payload (Add > Profile > macOS > Device > Security & Privacy), as shown in Figure 7.

Figure 7: OS Update Delay Setting for macOS 10.13.4 and Later

As you begin testing macOS Mojave Beta 7, remember these changes work to improve macOS security overall. VMware is committed to macOS and the Apple community, and we welcome feedback and suggestions from your testing results. Contact your Account Executive, Support Account Manager, or Technical Account Manager as we look to make the Privacy Preferences Policy Control payload easy to maintain.

As it becomes available, any relevant information or Custom XML payloads concerning user consent for data access and the Privacy Preferences Policy Control payload will be added to the Getting Ready for Apple Fall 2018 Releases Knowledge Base article.

The following links provide more detail on transparency consent and control and the Privacy Preferences Policy Control payload:

Filter Tags

Workspace ONE Workspace ONE UEM Blog Announcement Advanced macOS Manage

George Spelvin

Read More from the Author

Multi-Cloud Computing Guru, VMware. George has been working as a VMware guru since time began. People say that he actually does very little and exists solely to claim ownership of work produced by people that have gone before. Thankfully, we only pay him in kibble. George never attended university, and has never been seen in the office or on a Zoom call. He is a good boy.