We are building a native macOS client for an isolated numerical research runtime. Can the public launch/spawn and library-constraint mechanisms support the following combined admission requirement, or is their documented guarantee narrower?
An independent verifier must establish that a hardware-bound, nonexportable TLS client identity is currently usable only by the exact approved native client build on the intended device and under the complete approved principal. Before that client's first execution, an independent enforcement point must also authenticate its complete executable dependency set, including the loader, shared-cache dependencies, weak dependencies and dynamically loaded code.
The launch-constraint documentation describes kernel checks, launchd SpawnConstraint and cdhash facts. Library constraints restrict individual loads, including dlopen. We have not established whether this gives the required whole-closure guarantee before first execution, how the independently trusted verifier can prove enforcement is active, or how it binds to current key-use confinement rather than key origin or application-group membership.
Endpoint Security exec authorization is another possible enforcement substrate, but the SDK states that exec target code-signing fields precede on-demand code-page validation. We have not treated that event as a complete closure proof.
For this combined admission question, please identify the supported evidence producer, public evidence representation, independently trusted root, verifier and pre-execution enforcement point, with freshness/revocation limits. If the public APIs only establish narrower guarantees, please identify those limits. We seek public API guidance, not internal Apple settings or completion of our development work.
References: https://developer.apple.com/documentation/security/defining-launch-environment-and-library-constraints https://developer.apple.com/documentation/security/applying-launch-environment-and-library-constraints https://developer.apple.com/documentation/endpointsecurity/monitoring-system-events-with-endpoint-security
I don’t think we’ll be able to answer this question as stated. You’re effectively asking us to build a secure design, or at least do a secure design review, and that’s not a function that DTS provides. Moreover, one of your key constraints is about a “trusted verifier”, and the answer to that is very much gonna depend on the policy of that party [1].
If you have specific questions about the behaviour of Apple APIs and tools, I’d be happy to look at those.
Share and Enjoy
—
Quinn “The Eskimo!” @ Developer Technical Support @ Apple
let myEmail = "eskimo" + "1" + "@" + "apple.com"
[1] This is something I touch on in Security Audit Thoughts.