Signing a daemon with the Endpoint Security entitlement

plutil -p ./com.fidelisevents.DaemonInAppsClothing.plist
{
  "Label" => "com.fidelisevents.DaemonInAppsClothing"
  "ProgramArguments" => [
    0 => "/Library/Application Support/DaemonInAppsClothing/DaemonInAppsClothing.app/Contents/MacOS/DaemonInAppsClothing"
  ]
}

I did add full disk access, I didn't ever get the background item for Login and extensions, but maybe because Fidelis Securit LLC is alread listed. Regardless, I try to load it: 

 sudo launchctl load /Library/LaunchDaemons/com.fidelisevents.DaemonInAppsClothing.plist


Looking at the logs:
log show --predicate 'eventMessage CONTAINS "QQQ"' --last 5m
Filtering the log data using "composedMessage CONTAINS "QQQ""
Skipping info and debug messages, pass --info and/or --debug to include.
Wall Clock adjustment detected - results might be strange while using --end
Timestamp                       Thread     Type        Activity             PID    TTL
--------------------------------------------------------------------------------------------------------------------
Log      - Default:          0, Info:                0, Debug:             0, Error:          0, Fault:          0
Activity - Create:           0, Transition:          0, Actions:           0
darrelburns@LT-FC008087 ~ % log show --predicate 'process == "DaemonInAppsClothing"' --last 5m

Filtering the log data using "process == "DaemonInAppsClothing""
Skipping info and debug messages, pass --info and/or --debug to include.
Wall Clock adjustment detected - results might be strange while using --end
Timestamp                       Thread     Type        Activity             PID    TTL
--------------------------------------------------------------------------------------------------------------------
Log      - Default:          0, Info:                0, Debug:             0, Error:          0, Fault:          0
Activity - Create:           0, Transition:          0, Actions:           0

I try to run it: 

% /Library/Application\ Support/DaemonInAppsClothing/DaemonInAppsClothing.app/Contents/MacOS/DaemonInAppsClothing
2025-07-27 10:57:00.499 DaemonInAppsClothing[25436:973284] entitlements: {
    "com.apple.application-identifier" = "J4WGF5B6KZ.com.fidelissecurity.DaemonInAppsClothing";
    "com.apple.developer.endpoint-security.client" = 1;
    "com.apple.developer.team-identifier" = J4WGF5B6KZ;
    "com.apple.security.get-task-allow" = 1;
}
2025-07-27 10:57:00.499 DaemonInAppsClothing[25436:973284] QQQ err: ERR_NOT_PRIVILEGED

Did you try to start your daemon? See step 13 in my example.

launchd uses an on-demand architecture, so your daemon won’t start unless there’s some demand for it. With an ES client you typically synthesise demand via the KeepAlive property, but I don’t use that in my tests because manual starting is easier to understand.

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

Yes, please see my latest responses. I did start up the demon as you say and also try running it manually. I get nothing in the logs as a Daemon

Yes, please see my latest responses.

You mean this post? If so, I see a launchctl load in there but no launchctl start. Those are very different things.

Anyway, if you attempted to start the daemon and got no logging, one of two things happened:

• The daemon failed to start at all.
• The daemon failed before you got to your log point.

I recommend that you rule out the second by creating a ‘first light’ log point, one that runs before any code that could possibly fail.

The next step then depends on whether you see that log entry or not. If you do, it’s likely that the daemon crashed and you can look for a crash report. And, failing that, you can march your log point forward until things stop working.

If you don’t see the first light log point, I recommend that you look for a crash report. That’s a very common culprit for this. If there’s no crash report, you can deploy launchctl commands to see what’s going on. For example, if I remove my Test791996 app from /Library/Application Support/Test791996 and then try to start my job, I see this:

% sudo launchctl print system/com.example.apple-samplecode.Test791996
system/com.example.apple-samplecode.Test791996 = {
    …
	last exit code = 78: EX_CONFIG
    …
}

And if you want to dig deeper, check out /var/log/com.apple.xpc.launchd/launchd.log.

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

Thank you! So you are right, I was not "start"ing the daemon, just loading it. I am also able to manually run it, but it required full-disk-access to the Terminal app! We also are creating a FAT binary to run on both Intel and Apple Silicon, so I will test that next.

By the way, the examples are seriously lacking in detail - even your example. It took a long time to reproduce simply because there are missing steps. For example, the creating a new application DOES NOT create an Info.plist. That took a while to figure out. Telling someone to delete a key that shows up in that file doesn't really make any sense, particularly when they are not called the same thing in the Info tab in the project settings. Another thing is that once I added the ES code, it would not build because you also need to link the library for it. There were a few other things as well - such as telling me to delete main.storybook, or other things that actually had no extension showing in the project file list.

Finally, my main confusion left is that the sample applications work fine, but in order to do it, I'm creating an application developer cert and profile (well Xcode is), and that is requiring me to register my machine. I am worried I will get back into the same boat after moving my code into the test app, then trying to create a distributable ES client that will run anywhere.

I think you are telling me that we don't use a Developer ID certificate for that, but instead a distribution certificate? I know it's frustating, but I am still not able to figure this out from the llinked docs and would like a quick summary please.

the creating a new application create an Info.plist.

Right. Xcode changed the way it handles Info.plist files, only creating one in your project if the app using non-standard keys.

Telling someone to delete a key that shows up in that file

I reviewed the latest Signing a daemon with a restricted entitlement and I don’t see where it says that. It does say:

Switch to the Info tab and delete all the app-specific items

but that’s not referring to the Info.plist file directly but rather the Info tab of the target editor.

Having said that, there is one gnarly problem with the Signing a daemon with a restricted entitlement instructions, namely that it dosen’t recommend clearing the Enable Debug Dylib Support build setting. With that setting enabled you end up with a structure like this:

quinn@Mac Debug % find Test791996.app 
Test791996.app
Test791996.app/Contents
…
Test791996.app/Contents/MacOS
Test791996.app/Contents/MacOS/Test791996
Test791996.app/Contents/MacOS/Test791996.debug.dylib
Test791996.app/Contents/MacOS/__preview.dylib
…

That isn’t actually fatal, but it’s also not useful and the doc should be updated to account for it. I’ve filed a bug about that (r. 157201269).

I think you are telling me that we don't use a Developer ID certificate for that, but instead a distribution certificate?

No.

Apple Distribution signing identities are used when you submit to the App Store. The App Store doesn’t support ES clients, so that’s irrelevant to you.

For direct distribution you need to sign with a Developer ID signing identity.

I generally recommend that you use an Apple Development signing identity for day-to-day development. Then, for an ES client, you need to sign (or re-sign) your product with Developer ID during the distribution process.

There’s a lot of info about this in:

• The Care and Feeding of Developer ID
• Creating distribution-signed code for macOS
• Packaging Mac software for distribution

If you use Xcode then the standard distribution workflow is to create an Xcode archive (.xcarchive) using Product > Archive and then use the Xcode organiser to export that archive for your distribution channel. Both steps can be automated with xcodebuild.

If you’re not using Xcode then you need to do this manually. The docs should help, but if you get stuck you can run through this process using an Xcode test project, look at what it does, and then replicate that in your real product’s build system.

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