Supported NSDataAccessSecurityPolicy schema and exact-owner allowlist on macOS

Privacy & Security General
QuietCanaryLab OP
Created
Replies 5
Boosts 0
Views 1k
Participants 3

For macOS 26.7.1 (25G241), Xcode 27.0 (27A266a), and macOS SDK 27.0, we request the supported, exact Info.plist schema for NSDataAccessSecurityPolicy: its value type, literal key names and nesting, item types, and identity-selector grammar.

Can the policy allow only the owning process signed with a specific Team ID and signing identifier, without allowing all applications signed by that Team?

Are cdhash or designated-requirement selectors supported, and how do process and installer/package identities differ?

Please clarify the relationship to user consent and Full Disk Access exceptions, and confirm whether this configuration is supported for the macOS build listed above.

Please provide primary documentation or an authoritative schema, rather than a schema inferred from NSUpdateSecurityPolicy.

Answered by Etresoft in 908323022

For context, it looks like NSDataAccessSecurityPolicy was mentioned once in a WWDC 2023 video (What's new in Privacy)..

And that's the extent of its documentation. I don't see any existing 3rd party or system apps that have ever used it.

Replies  5
Boosts 0
Views  1k
Participants  3
Etresoft OP
Recommended

For context, it looks like NSDataAccessSecurityPolicy was mentioned once in a WWDC 2023 video (What's new in Privacy)..

And that's the extent of its documentation. I don't see any existing 3rd party or system apps that have ever used it.

DTS Engineer OP
Apple
And that's the extent of its documentation.

Indeed. Specifically, look at the slide shown at 21:32. AFAICT the schema illustrated by that slide is what’s actually implemented.

Clearly we should have proper documentation for this and I encourage you to file a bug requesting that. Please post your bug number, just for the record.

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

Specifically, look at the slide shown at 21:32. AFAICT the schema illustrated by that slide is what’s actually implemented.

That's still confusing. Under "AllowPackages", it says "TEAMID_ABC". Then under "AllowProceses", it has the same "TEAMID_ABC" as an array key pointing to what looks like a bundle identifier.

I would expect a "package" to use a bundle ID. Processes typically implies PID for reference. Obviously PIDs aren't possible in this context. So is that a bundle ID? Or a label prefix from launchd? And what about a bundle that has sub-bundles with identical bundle ID prefixes? Would a top-level prefix allow both the bundle at the top level and contained bundles?

Is the "TEAMID_" prefix required? Or should this be the actual Team ID? If the keys said "TeamIDs" and "BundleIDs", then it would be more straightforward.

DTS Engineer OP
Apple

AllowPackages refers to installer packages. It extends the allowlist to include any installer packages signed by the listed teams.

AllowProcesses is somewhat misnamed. It doesn’t list processes per se, but it specifies a list of executables, and it extends the allowlist to include any process whose main executable is listed.

The items are not bundle IDs but rather code signing identifiers. This is a concept I explain in some detail, with links to docs, in Code Signing Identifiers Explained but, in short:

  • In all cases, the signer gets to choose the code signing identifier.
  • For bundled code, it defaults to the bundle ID.
  • For non-bundled code, we recommend that the signer chooses a string that is what the bundle ID would’ve been if the code were bundled.

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

This is a concept I explain in some detail, with links to docs, in Code Signing Identifiers Explained

Thanks for the rabbit hole. Found some useful things in there.