macOS 11.x system reported an error when using endpoint security

This is .entitlements file:

Yeah, that’s a problem.

To understand what’s going on here, you need to understand that:

• com.apple.developer.endpoint-security.client is a restricted entitlement.

• Meaning that its use must be authorised by a provisioning profile.

See TN3125 Inside Code Signing: Provisioning Profiles for a lot more background on that.

For this to work, the system must be able to tie your code to your profile. It does this via the App ID entitlement [1]. You’re not including that in your entitlements and thus the system fails to associate your profile with your code, which prevents it from authorising the use of your entitlement.

Now, this works on macOS 12 and later because it added a special case to assume that a profile embedded in an app bundle is appropriate for that app. However, that’s not something you should rely on [2]. Rather, when signing with a restricted entitlement, always include the App ID and Team ID entitlements.

Share and Enjoy
—
Quinn “The Eskimo!” @ Developer Technical Support @ Apple
let myEmail = "eskimo" + "1" + "@" + "apple.com"

[1] application-identifier on iOS and its child platforms; com.apple.application-identifier on macOS.

[2] For example, apps distributed via TestFlight can run into the problem discussed in TestFlight, Provisioning Profiles, and the Mac App Store.

Thank you. This is the directory structure of my App

.
└── Contents
    ├── Frameworks
    ├── Info.plist
    ├── MacOS
    │   ├── UES
    ├── Resources
    │   ├── UES.icns
    ├── _CodeSignature
    │   └── CodeResources
    └── embedded.provisionprofile

This sentence "always include the App ID and Team ID entitlements", I don 't quite understand. I haven't been learning macOS for long. May I ask what I should do? ^_^

Yeah, this stuff is complex )-: Let me clarify this by example.

My go-to suggestion for setting this up is to do what Xcode does. In fact, we have that in the official documentation, namely Signing a daemon with a restricted entitlement.

If you follow that process and build the test project with Xcode, you see this:

% codesign -d --entitlements - Test782415.app
…
[Dict]
	[Key] com.apple.application-identifier
	[Value]
		[String] SKMME9E2Y8.com.example.apple-samplecode.Test782415
	[Key] com.apple.developer.endpoint-security.client
	[Value]
		[Bool] true
	[Key] com.apple.developer.team-identifier
	[Value]
		[String] SKMME9E2Y8
	[Key] com.apple.security.get-task-allow
	[Value]
		[Bool] true
% security cms -D -i Test782415.app/Contents/embedded.provisionprofile | plutil -p -
{
  …
  "Entitlements" => {
    "com.apple.application-identifier" => "SKMME9E2Y8.com.example.apple-samplecode.Test782415"
    "com.apple.developer.endpoint-security.client" => 1
    "com.apple.developer.team-identifier" => "SKMME9E2Y8"
    "keychain-access-groups" => [
      0 => "SKMME9E2Y8.*"
    ]
  }
  …
}

Note how the ‘app’ is signed with the com.apple.application-identifier entitlement, and its value matches the value in the provisioning profile’s allowlist. This is what you’re aiming for.

Oh, and the Team ID (com.apple.developer.team-identifier) as well, just for completeness.

Now, this doesn’t mean that you need to build your product with Xcode. You are free to build your product with your existing build system. However, the final result should look like that shown above, that is:

• Your daemon is in an app-like wrapper.

• That wrapper has an embedded provisioning profile.

• And the daemon is signed with the entitlements it needs (in this case com.apple.developer.endpoint-security.client) and the standard entitlements that link it to its profile (com.apple.application-identifier and com.apple.developer.team-identifier).

Share and Enjoy
—
Quinn “The Eskimo!” @ Developer Technical Support @ Apple
let myEmail = "eskimo" + "1" + "@" + "apple.com"