Launch and Environment Constraints Overview

The talk opens with earlier macOS TCC bypasses that abused system applications. Attackers copied signed Apple apps out of the protected system volume, planted plugins or dylibs where the apps would load them, or used a daemon's bundle-loading option. These logic bugs were easy to exploit and prompted Apple to add launch constraints in Ventura. Each constraint applies to the process itself, its parent, or its responsible process, and binaries are grouped into categories recorded in the trust cache.

The speaker shows how to pull the trust cache out of the OS launch policy files and read the category column. He then explains where the constraint definitions live in the AMFI kernel extension, how to get the binary from a kernel development kit, and how the DER-encoded data describes each category. Constraints block copied system binaries from running outside their trusted location, which stops the earlier plugin and bundle tricks. For third-party software, he argues the picture is weaker. Environment constraints extend the mechanism to apps, but the open command can still pass environment variables and arguments. For global XPC daemons, the responsible process turns out to be the service itself, so the constraint does not stop a random client from starting it.

The main takeaway is that launch constraints are a solid design for Apple's own binaries but cover few of the third-party bugs seen in practice. Developers should still perform proper client validation for XPC services. Library load constraints, which accept frameworks only from listed team IDs, are practical when every plugin's team ID is known.