Title: Supported OS-enforced restriction of Keychain access while retaining App Sandbox and App Group UDS

I’m designing a small, controlled macOS test harness.

Two separately signed, sandboxed applications communicate through a UNIX-domain socket in an App Group container. They run as non-root processes in a GUI user session. One application also launches a child that inherits its sandbox and an existing socket descriptor.

Is there a documented, supported OS policy that preserves this IPC arrangement while preventing the test processes from retrieving, using or modifying credentials, including items in their own Data Protection Keychain access groups and reachable file-based keychains? The policy must also prevent creating credential stores/items outside the permitted test resources.

Using a macOS-style TeamID-prefixed App Group avoids that group providing Keychain sharing, but does not establish denial of the remaining Keychain operations. Empty stores, avoiding API calls and relying on users refusing prompts are insufficient for this requirement.

If a different execution context or isolation architecture is required, could you identify the supported mechanism and relevant documentation? I’m seeking platform guidance, without relying on private APIs or unsupported custom sandbox profiles.

You wrote:

Written by AT23 in 852366021

One application also launches a child that inherits its sandbox and an existing socket descriptor.

and:

Written by AT23 in 852366021

Is there a documented, supported OS policy that preserves this IPC arrangement while preventing the test processes

[my emphasis]

So am I to assume the child process in the first quote is the test process in the second?

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

Hi Quinn, thank you for asking — I should have made the process roles clearer.

The child is one of the test processes, but the credential restriction is not limited to it:

  • A: the sandboxed parent/driver application.
  • B: A’s child, inheriting its sandbox and an existing socket descriptor.
  • C: the separately signed, sandboxed receiver application communicating with A through the App Group UNIX-domain socket.
  • O: a separate observer collecting bounded test evidence, which also needs its permitted resource access defined.

The credential restriction needs to cover all four roles, using controls appropriate to each role’s execution context. I am not assuming that B inherits A’s Keychain access-group membership merely because it inherits A’s sandbox.

This is a controlled synthetic test harness whose code we own. The requirement concerns OS-enforced prevention of credential retrieval, use, modification, and out-of-scope creation — including otherwise accessible own-group Data Protection Keychain items and file-based keychains. It is not a blanket prohibition on harmless Security.framework operations, such as public-certificate or trust lookups.

Does a supported execution context or isolation arrangement provide that restriction while preserving the parent–child relationship and local IPC described above?

So this is all App Sandbox, right? Not some unsupported SBPL shenanigans?

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