Supported receiver-confinement guarantee for anonymous XPC connections on macOS 27.0.1

I’m assessing whether the public C XPC APIs provide the recipient guarantee needed for a local security boundary.

The proposed path uses a dedicated anonymous listener, a transferred xpc_endpoint_t, and xpc_connection_create_from_endpoint. Before releasing protected data, I need to establish which process occurrence can receive it and whether that binding continues to hold through delivery. Here, “process occurrence” means one running instance, including protection against confusing it with a later instance that reuses its PID.

The target reports macOS 27.0.1 (26A434), Darwin 27.0.0, arm64, and xnu-13432.1.9~1/RELEASE_ARM64_T6000. The selected Command Line Tools SDK reports macOS 27.0, SDK build 26A425. These are read-only inventory results; I have not run an XPC prototype for this question.

Is there a supported public API contract that lets the sending application, or a separately authorized local verifier, establish before protected data becomes accessible that this connection’s actual receiver is the authenticated process occurrence and remains confined to it for that send?

I specifically need to understand whether that guarantee covers endpoint copying or forwarding, repeated or concurrent connections created from one endpoint, process replacement, queued messages, and replies or access-capable attachments. I am asking about the selected C connection API; I do not assume equivalent behavior across the C and Swift session APIs.

If a supported mechanism exists, which APIs, OS versions, privileges or entitlements are required, and where is the guarantee documented? If the public API does not expose this guarantee, a clear statement of that limit would help me choose an appropriate transport boundary.

The distinction I need to resolve is between authenticating a peer at one point and ensuring that protected outgoing data reaches only that same process occurrence. I am seeking the supported security contract, without requesting access to private implementation details.

Answered by DTS Engineer in 909908022

I’m not sure if you’ve seen the Validating Signature Of XPC Process thread but, if not, there’s a link to it in XPC Resources. I recommend that you read that first and then come back here with your follow-up questions.

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

Accepted Answer

I’m not sure if you’ve seen the Validating Signature Of XPC Process thread but, if not, there’s a link to it in XPC Resources. I recommend that you read that first and then come back here with your follow-up questions.

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

Thank you, Quinn. I've read Validating Signature Of XPC Process and the linked Outgoing XPC message goes through to untrusted Peer discussion.

I understand the distinction between authenticating the sender of a received message and authenticating the actual recipient before an outgoing protected message becomes accessible.

My remaining question concerns the latter guarantee.

For a dedicated anonymous listener, a transferred xpc_endpoint_t, and xpc_connection_create_from_endpoint on macOS 27.0.1, is there a supported public mechanism that binds protected delivery to the authenticated receiver process occurrence and preserves that confinement despite endpoint forwarding, concurrent connections, process replacement, or queued messages?

I'm not asking how to validate a received message's sender. I need to establish the destination and continuing confinement of an outgoing protected message before releasing its contents.

If the public C XPC API does not provide that guarantee, could you confirm that limitation? That would help us determine whether this security boundary requires a different transport architecture.

Thank you for your guidance.

Written by sevenislove in 910755022

is there a supported public mechanism that binds protected delivery to the authenticated receiver process occurrence … ?

No.

And even if there were, there’s no way to stop the receiver from passing the contents of the message to a difference process. If you want to do that sort of thing, you have to prevent the receiver from setting up any IPC channels to untrusted processes.

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