My question is: Do I need two App IDs? One for my launch daemon in order to sign it properly, allowing it to use the Endpoint Security framework. One for the container app.
My understanding is that my existing launch daemon can perform the endpoint security requirements I need. So far, I have had just one App ID for my container app that lives in /Applications. I have applied for the endpoint security restricted entitlement and have this for development now.
Do endpoint security items have go in Library/SystemExtension? Can my launch daemon live in Library/LaunchDaemons and still use the Endpoint Security framework?
Every executable that uses restricted entitlements, those that must be authorised by a provisioning profile, must have its own App ID [1]. That ties the executable to the profile that authorises its entitlement claims. I talk about this in depth in TN3125 Inside Code Signing: Provisioning Profiles.
No. There are two ways to package an ES client:
-
As a system extension
-
As a
launchd
daemon
In the first case the sysex is embedded within your app and you install it using System Extensions framework. The exact location where it gets installed is an implementation detail.
In this second case you can put your launchd
daemon wherever you want. However, ES requires that its clients be signed with a restricted entitlement, so you need to package it with a provisioning profile. For more on that, see Signing a daemon with a restricted entitlement.
If you already have an launchd
daemon it often makes sense to put your ES client in that. However, there are advantages to sysex packaging, something we explain in WWDC 2020 Session 10159 Build an Endpoint Security app.
Share and Enjoy
—
Quinn “The Eskimo!” @ Developer Technical Support @ Apple
let myEmail = "eskimo" + "1" + "@" + "apple.com"
[1] Don’t use the same App ID for two different executables in the same product. I once spent weeks tracking down a weird problem caused by a developer doing that |-: