TCC Round Up

Now that macOS Mojave has been released into the wild, a quick recap of changes relating to Transparency, Consent, and Control (TCC).

What changes?

In certain circumstances, the first time you run an app, you may be prompted to allow it to access data such as your contacts, or maybe hardware such as the camera, or possibly even control your computer.

This doesn’t have to be the first time you run an app either. For example, a web browser such as Google Chrome won’t access your camera or microphone, but at some point it may, and when it does, that is when you’ll see the prompt.

Additionally, if the user doesn’t acknowledge the consent prompt, by clicking either of the buttons, and leaves it alone, the consent prompt will eventually disappear after a certain “time out” period, it will also assume that the user does not want to provide consent.

Worse, a typical schedule runs when the user isn’t even present, and so the prompts go without response, and the events time out.
Worse still, a timeout (the system defaults to two minutes) doesn’t re-prompt, but assumes the answer is “no”.

Dave Nanian @ Shirt Pocket

Can it be disabled?

Unlike System Integrity Protection (SIP), these protections cannot be disabled.

Accessing protected folders from the command line.

You will no longer be able to access certain protected folders in user profiles that contain protected information.

To access these folders, or other TCC protected folder locations, you need to add the Terminal (or whatever your preferred terminal app is) to the Full Disk Access section of the Privacy tab in the Security & Privacy preference pane, or by using a Privacy Preferences Policy Control Payload (PPPCP for short).

A list of protected locations collated by a number of macadmins members (check the pinned items in #tcc for the Google Sheet created by @erik):

  • /Users/username/Library/Application Support/CallHistoryTransactions
  • /Users/username/Library/Application Support/com.apple.TCC
  • /Users/username/Library/Application Support/AddressBook
  • /Users/username/Library/Application Support/CallHistoryDB
  • /Users/username/Library/IdentityServices
  • /Users/username/Library/Calendars
  • /Users/username/Library/Preferences/com.apple.AddressBook.plist
  • /Users/username/Library/Messages
  • /Users/username/Library/Mail
  • /Users/username/Library/Safari
  • /Users/username/Library/Suggestions
  • /Users/username/Library/Containers/com.apple.Safari
  • /Users/username/Library/PersonalizationPortrait
  • /Users/username/Library/Metadata/CoreSpotlight
  • /Users/username/Library/Cookies
  • /Users/username/Library/Caches/CloudKit/com.apple.Safari
  • /private/var/db/dslocal/nodes/

How do I manage it?

Apple have provided new MDM Configuration Profile payloads.

Profiles for PPPCP can be built by using my tccprofile.py tool, Erik Burglund’s Profile Creator, JAMF’s PPPC-Utility, or by artisinally hand crafting them (though you’re likely to drive yourself mad if you do this).

You will absolutely need an MDM to deploy these profiles as they cannot be deployed direct to a machine through a package, or other installation method.
This will mean either a DEP to MDM enrolment workflow, or through User Approved MDM (users manually enrol their Mac into MDM).

Apple introduced the concept of User Approved MDM in macOS High Sierra. It’s here to stay, and we will see more profiles require this in the future.

Rich Trouton has a git repo with a number of profiles for various applications, and JAMF has a profile that has been prepared for deployment in JAMF environments to pre-approve their binaries.

Why can’t I remove items from Microphone, Camera, etc?

Not all items can be removed from the relevant privacy setting.

For example, apps that are allowed or have blocked access to the camera or microphone can only have their check box ticked or unticked. It’s also not possible to add apps to the Camera or Microphone preferences directly, and any PPPCP profile can only explicitly deny an app access to the camera or microphone.

You can however reset the TCC database (both the user and system database) by using the tccutil tool. However, this will require providing Full Folder Access to the Terminal app (or terminal app of your choice).

Haircut from the macadmins slack has this great gist to reset it with a simple python script, as well as this great write up on making it a Self Serve item in JAMF.

How will I know what to approve?

You will need to test existing management scripts and the applications/tools that get deployed to your Mac fleet. Not everything requires approval, but there are apps that will surprise you.

To help understand what you need to approve, you can parse the TCC log stream (just don’t cross the streams).

Importantly, you can only approve apps or scripts that have been code signed.

It can’t be that simple?

Unfortunately, this is true. It isn’t all that simple.

Over the last few weeks as this has been tested out by members of the macadmins slack (join up if you haven’t already!), there have been many discoveries about apps that ask for access to control themselves, or scenarios where the parent process isn’t identified correctly in the TCC User Consent dialog.

There are also scenarios where if a python script is called from a Launch Daemon or Agent, the user will be prompted to allow the specific script control of the computer or access to protected data (depending on what is being processed).

PPPCP profiles should not be installed on a Mac that isn’t running macOS Mojave 10.14 as they will not be applied after upgrading to macOS Mojave 10.14*. Check your MDM to see how you can “scope” or “tag” profiles/devices to avoid deploying PPPCP profiles to Mac hardware that isn’t running macOS Mojave, or to Mac hardware that is running macOS Mojave.

*Note: This highlights a need for Apple to implement either a “check in with MDM after upgrade” routine, or a means by which a Mac system can be told to check in with an MDM.

Should I approve shells or interpreters?

Generally speaking, it’s best to avoid being too general with what is approved in a PPPCP profile. For example, if you approve /usr/bin/python in a PPPCP profile to control the Mac, then any python script that runs code to control your computer will be able to do that.

If at all possible, only whitelist what needs to be approved.

Can I approve scripts?

Yes you can, however you will need to make sure that the script/tool being approved is code signed, and you will need to create a PPPCP profile for that script.

Code signed scripts have the code signing details stored in extended attributes (xattr). When you deploy the script, these attributes must be preserved when put onto the target Mac.

You will also need a code signing certificate in order to code sign scripts, software, etc. Apple provides more information about code signing here.

Can I code sign third party apps that aren’t code signed?

Technically yes, however it is strongly recommended that if at all possible, rely on the developer to code sign the app.

Code signing is a way of indicating the app has not been changed since it was signed, identify where the app came from or who signed it, and if the app is trustworthy.

By code signing an app that you have not created or are the developer of, you effectively take responsibility for making sure it does not act maliciously, etc.

Should I create a single profile, or multiple profiles?

It’s ultimately a decision to make based on the environment that these are deployed in.

The granularity of multiple profiles is a good thing, but you do have to be mindful of how profiles are applied on a macOS system. If there are conflicting payloads of the same type, then the most restrictive payload wins.

Creating a large profile with multiple payloads in it will minimise the chance of having conflicting payloads in multiple profiles, however it will be more cumbersome to make changes to specific payloads, especially when the profile applies to multiple machines that may have different needs.

PPPCP profiles have been deployed, but nothing shows up in the Security & Privacy preferences pane.

This seems to be by design (presently), but does not help the user or administrator know if a profile is in place or deployed correctly.

The only time an app will show up in the Security & Privacy preference pane, is when it has been approved directly by the user.

If this is something that you believe should be changed, then submit feedback/RADARs to Apple.

An app that used to work fine in macOS High Sierra, no longer works, and randomly crashes.

This may be because the app hasn’t been compiled/built properly for macOS Mojave 10.14.

This blog post goes into more detail about this issue.

What can I do to avoid triggering a TCC User Consent dialog?

For third party apps that are out of your control, the only course you can take is to send feedback to the app developer. In some cases, they will be able to re-write code to avoid code that will trigger these consent dialogs, but in some cases that won’t be possible.

If you are writing your own scripts for managing macOS, or just to make your life easier, then you may need to re-write your scripts to avoid things that will trigger a consent dialog. You will need to test your scripts to find out if it will trigger a consent dialog.

This is still all confusing.

The macadmins slack is a fantastic resource for Mac admins, especially for those that are one man shops. Join the #tcc channel and join in the discussions there.

Feedback.

The best way that we can affect change is by submitting feedback to Apple through either the Apple Seed program or the Developer program.

If you’re not in the Apple Seed program, then reach out to your Apple SE and ask for an invite to join in.

Provide thorough details of the issue, steps to replicate, screenshots, videos, etc, and include impact statements that describe what the impact is to IT staff, end users, as well as the number of devices this applies to.

Joining the Developer program is also a good idea if you can’t join the Apple Seed program.