I’m designing a macOS privileged-service boundary and I’d like to clarify whether a process-occurrence authentication pattern previously described by Apple DTS is a supported shipping security contract, rather than just behaviour that happens to work on current macOS. Target: current macOS 26.x, using public APIs only. Threat model An arbitrary hostile process may run as the same ordinary, non-admin login user as the application. The attacker can launch an exact second copy of the legitimately signed requester binary. The attacker cannot obtain administrator / Touch ID authorization and does not control root, SIP, Recovery, the kernel, or the code-signing infrastructure. Desired property After a fresh Human-authorized operation, a root LaunchDaemon should grant authority to one specific requester process occurrence, not to every process having the same code-signing identity. Apple DTS thread 842442 describes a pattern based on:
- launching the requester suspended with posix_spawn(..., POSIX_SPAWN_START_SUSPENDED);
- obtaining a name/task port for that process;
- reading its TASK_AUDIT_TOKEN;
- resuming the process; and
- accepting only Mach messages whose kernel audit trailer identifies that same process occurrence.
Thread 842442 also describes this area as being on “thin compatibility ice”, which is why I do not want to build a security boundary on behaviour that Apple does not intend applications to rely on. My core question is: Can a shipping macOS application rely on a pre-bound audit_token_t obtained from a suspended child and compare it against the audit token in subsequent raw Mach message trailers as a supported security boundary for that exact process occurrence? In particular, I need to know whether the supported contract covers:
- distinguishing another process with the exact same signed executable;
- PID reuse after the original process exits;
- messages queued before or around sender termination;
- a Mach send right transferred to another process — does the receiver see the audit token of the process that actually sends each message?;
- later exec by the original process; and
- whether full audit_token_t equality is an appropriate supported comparison for this purpose.
If that is not a supported shipping contract, is there a current public XPC API that provides the equivalent property: binding one privileged-service session to one exact process occurrence rather than merely to its code-signing identity? I’m specifically trying to distinguish: code identity = this is an approved executable from mission authority = this one particular authorized process occurrence I’m happy with a negative answer if macOS does not expose a stable public contract for the latter. Related Apple DTS discussion: https://developer.apple.com/forums/thread/842442
Jumping in on this...
Is that essentially the use case you had in mind when pointing me to es_new_descendants_client?
What you're describing here:
The product is a local macOS application that coordinates AI-assisted software development work.
...is one of the primary use cases es_new_descendants_client was designed for.
Can it be used to ensure that only a selected descendant subtree may obtain/connect to a particular privileged XPC/Mach service, while another same-UID process running identical signed code outside that subtree cannot?
Your level of control is bound to your descendants, so you'll only see the actions of your children. However, you have full control over your children's activities.
Also, one thing to note is that the es_new_descendants_client does NOT have the same deadline limitations as the standard ES client, which DRAMATICALLY simplifies many approvals. For example, if you want the user permission for a particular exec, you can just ask the user and not approve the auth until the user consents. From the calling processes perspective, they'll just block in exec until you approve or deny.
After an allowed descendant obtains the endpoint/send right, is delegation of that endpoint/right to a non-descendant something this mechanism prevents or detects, or would I still need another boundary for that?
No, the API only applies to your descendants. However, I also think this kind of much broader activity is much more difficult to detect and properly control, very quickly pushing you back into full ES client territory. That may be valid, but I think it needs to be understood as a separate problem set with a different set of solutions.
Finally, would the Endpoint Security client entitlement be considered appropriate for a broadly shipped developer tool whose use of ES is specifically to enforce this per-operation authority boundary, rather than for a traditional endpoint-security product?
I don't know where things stand here, but the intention is that es_new_descendants_client can be used much more broadly than the ES API. In practice, that will probably mean a new self-add entitlement (meaning, you don't need our specific approval).
__
Kevin Elliott
DTS Engineer, CoreOS/Hardware
