Testing endpoint security on a virtual Mac

I am having difficulty getting my container app with an embedded endpoint security extension to work on a virtual Mac.
My virtual Mac has system integrity protection turned off. I have used spctl and System Settings to allow applications from anywhere. I am using the development entitlement profile to sign my container app. When I run my app, it crashes with Termination Reason: COODESIGNING 1 Taskgated Invalid Signature. I assume this has to do with the app being signed with my developer profile that contains a list of Macs that can run the software. How can test my endpoint security extension on a virtual Mac?

Answered by DTS Engineer in 826013022

Endpoint Security requires a restricted entitlement, one that must be authorised by a provisioning profile. A development profile is limited to a specific set of Macs. I discuss the background to this in TN3125 Inside Code Signing: Provisioning Profiles.

So, as ssmith_c says, you have to add your Mac’s provisioning UDID to your profile. However, this presents complications for VMs.

For Intel VMs, everything should be fine.

For Apple silicon VMs, if your VM was created on macOS 15 then its provisioning UDID will be in a format that can’t be registered with the Developer website )-: See this thread for the details.

I typically work around that using a VM created on macOS 14 for this sort of stuff.

IMPORTANT The above isn’t about the VM host or guest OS, it’s about the OS on which the VM was created. If you create a macOS 15 VM on macOS 14, its provisioning UDID is set by macOS 14 at creation time. You won’t have this issue hosting that VM on macOS 14 or macOS 15.

Oh, and that speaks to another important point: Don’t re-create a new VM for each test. Rather, create a single VM and then, between tests, restore it from a snapshot (or clone, or whatever your VM software calls it). That has two benefits:

  • You don’t have to re-create your provisioning profiles for each test run.

  • You’re less likely to bump into the device limit that ssmith_c mentioned.

Share and Enjoy

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

[1] Turning off SIP won’t help with this. Once SIP is disabled you can apply boot arguments to disable entitlement checking, but it’s better to avoid that path if you can.

My virtual Mac is running 15.2.

For real devices, someone (it might be the Account Owners, or perhaps any Admin) can go to the Devices section of the Accounts tab of developer.apple.com, and add the "Provisioning UDID" of a device to the list of devices. I've never tried this for a virtual Mac.

You can find the Provisioning UDID of your Mac in the Hardware section of System Information.

Bear in mind that you can have a maximum of 100 devices on your developer account, and that list can only be pruned once a year. So if you re-create your virtual Mac often, and it has a different Provisioning UDID every time, you may run out of devices.

If you build your software on a Mac with Xcode, with automatic signing turned on, that Mac will be automatically added to the list of developer devices. The process of manually adding to the list is only necessary for pure "victim" devices which need to run development software.

Endpoint Security requires a restricted entitlement, one that must be authorised by a provisioning profile. A development profile is limited to a specific set of Macs. I discuss the background to this in TN3125 Inside Code Signing: Provisioning Profiles.

So, as ssmith_c says, you have to add your Mac’s provisioning UDID to your profile. However, this presents complications for VMs.

For Intel VMs, everything should be fine.

For Apple silicon VMs, if your VM was created on macOS 15 then its provisioning UDID will be in a format that can’t be registered with the Developer website )-: See this thread for the details.

I typically work around that using a VM created on macOS 14 for this sort of stuff.

IMPORTANT The above isn’t about the VM host or guest OS, it’s about the OS on which the VM was created. If you create a macOS 15 VM on macOS 14, its provisioning UDID is set by macOS 14 at creation time. You won’t have this issue hosting that VM on macOS 14 or macOS 15.

Oh, and that speaks to another important point: Don’t re-create a new VM for each test. Rather, create a single VM and then, between tests, restore it from a snapshot (or clone, or whatever your VM software calls it). That has two benefits:

  • You don’t have to re-create your provisioning profiles for each test run.

  • You’re less likely to bump into the device limit that ssmith_c mentioned.

Share and Enjoy

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

[1] Turning off SIP won’t help with this. Once SIP is disabled you can apply boot arguments to disable entitlement checking, but it’s better to avoid that path if you can.

Testing endpoint security on a virtual Mac
 
 
Q