Do you have System Integrity Protection (SIP) turned off?I had to turn this off for my endpoint development. Now I am waiting for an entitlement from Apple, so I can turn SIP back on and test my code on other people's computer.Todd

Also verify that your application is signed with the entitlements embedded.$ codesign -dvvv --entitlements :- netsq_endpoint_agent ... Authority=Apple Worldwide Developer Relations Certification Authority Authority=Apple Root CA Signed Time=Dec 29, 2019 at 9:35:56 AM Info.plist=not bound ... <?xml version="1.0" encoding="UTF-8"?> <!DOCTYPE plist PUBLIC "-//Apple//DTD PLIST 1.0//EN" "http://www.apple.com/DTDs/PropertyList-1.0.dtd"> <plist version="1.0"> <dict> <key>com.apple.developer.endpoint-security.client</key> <true/> <key>com.apple.security.get-task-allow</key> <true/> <key>com.apple.security.temporary-exception.mach-register.global-name</key> <array> <string>com.netsq.netsq_endpoint_agent</string> </array> </dict> </plist>(Oops. It is good to do this anyways. I see an unnecessary entitlement I need to remove)

To provide a concrete example, I created a HelloWorld command-line program, ranxcodebuild clean installpackaged it and sent it for notarization. The app had my Developer ID, TeamIdentifier, and a Signed Time.$ codesign -dvvv --entitlements :- HelloWorld.dst/usr/local/bin/HelloWorldExecutable=/private/tmp/HelloWorld.dst/usr/local/bin/HelloWorldIdentifier=HelloWorldFormat=Mach-O thin (x86_64)CodeDirectory v=20500 size=406 flags=0x10000(runtime) hashes=4+5 location=embeddedHash type=sha256 size=32CandidateCDHash sha256=946e6b1e139852546e7d3624b107c842c4f0522cCandidateCDHashFull sha256=946e6b1e139852546e7d3624b107c842c4f0522c26f2dba7aea8b93c668f9f8dHash choices=sha256CMSDigest=946e6b1e139852546e7d3624b107c842c4f0522c26f2dba7aea8b93c668f9f8dCMSDigestType=2CDHash=946e6b1e139852546e7d3624b107c842c4f0522cSignature size=4736Authority=Apple Development: XXXX XXXXXXX (XXXXXXXXXX)Authority=Apple Worldwide Developer Relations Certification AuthorityAuthority=Apple Root CASigned Time=Feb 5, 2020 at 3:49:08 PMInfo.plist=not boundTeamIdentifier=XXXXXXXXXRuntime Version=10.15.0Sealed Resources=noneInternal requirements count=1 size=176<?xml version="1.0" encoding="UTF-8"?><!DOCTYPE plist PUBLIC "-//Apple//DTD PLIST 1.0//EN" "http://www.apple.com/DTDs/PropertyList-1.0.dtd"><plist version="1.0"><dict/></plist>And here is the Notarization error log{ "logFormatVersion": 1, "jobId": "909e8ba7-4df5-4120-b35a-c4c0b21e921b", "status": "Invalid", "statusSummary": "Archive contains critical validation errors", "statusCode": 4000, "archiveFilename": "HelloWorld.pkg", "uploadDate": "2020-02-05T23:54:48Z", "sha256": "d6cc95c1e32bb038b654aea96b683a6f0e704d72b530187ea6fa081276635235", "ticketContents": null, "issues": [ { "severity": "error", "code": null, "path": "HelloWorld.pkg/HelloWorld.pkg Contents/Payload/usr/local/bin/HelloWorld", "message": "The binary is not signed with a valid Developer ID certificate.", "docUrl": null, "architecture": "x86_64" }, { "severity": "error", "code": null, "path": "HelloWorld.pkg/HelloWorld.pkg Contents/Payload/usr/local/bin/HelloWorld", "message": "The signature does not include a secure timestamp.", "docUrl": null, "architecture": "x86_64" } ]}

Thanks to everyone for your feedback. After reading your posts and following your links, I was able to figure it out. It turns out the fault was mine. (1) I did not have the necessary certificate, and (2) I had to do a manual codesign with the new certificateBefore when I did a codesign -dvvvv I could see that the binary was signed, but the "Apple Development" signing certificate (line 3 below) was not sufficient.$ codesign -dvvv --entitlements :- /tmp/helloworld.dst/usr/local/bin/helloworld ... Authority=Apple Development: XXXXXX (XXXXXXXXXX)After requesting and getting a "Developer ID Application" certificate, and then manually signing the binary with that, notarization started working for me again.$ codesign -s "Developer ID Application: XXXXXXXX (XXXXXXXXXX)" --options=runtime --force /tmp/helloworld.dst/usr/local/bin/helloworldcodesign -dvvv --entitlements :- /tmp/helloworld.dst/usr/local/bin/helloworld ... Authority=Developer ID Application: XXXXXXX (XXXXXXXXXX)So if the "Authority" field was "Apple Development: ...", notarization failed for me.When the "Authority" field was "Developer ID Application: ...", notartization succeeded.One last observation, I needed the --options=runtime option on the codesign command above to preserve the hardened runtime, another necessary condition for notarization.Thanks again for everyone's help!

I'm still trying to launch my command-line endpoint agent via launchd from an XPC request from the GUI application.Everything works fine with SIP turned off, but once SIP is turned back on, the endpoint agent exits with a status of -9.The console error message is:removing service since it exited with consistent failure - OS_REASON_CODESIGNING | When validating /usr/local/netsqllc/libexec/netsq_endpoint_agent: Code has restricted entitlements, but the validation of its code signature failed.The code has been signed with my "Developer ID Application" certificateThe package built with my "Developer ID Installer" certificateThe package has been notarized.And the application installed via the notarized package installer.My "request to use Endpoint Security was approved", but I had some problems with the instructions in the email. They seemed to indicate that this would be a GUI app and not a command-line app.For example, I cannot set the "Provisional Profile" for a command-line application.Any suggestions or Tech Notes for configuring the command-line application for Endpoint Security with SIP activated?Thanks,

I've gotten to this same point - same error message."sandboxd: [com.apple.sandbox.reporting:violation] Sandbox: endpointagent(10790) System Policy: deny(1) system-privilege 1016"I'll let you know if I find a solution. If you found something, please post what you found.Thanks,

I also saw a tccd message right before the sandbox information in the logs (and the sandbox killing of the program), and I realized that launching via launchd doesn't bring up the windows asking the user to allow the endpoint agent to run. I assume in my case the code isn't blessed by TCC, which might be part of the problem.For now I am trying some tricks to get that to work. I'll chime in with my results tomorrow.

Additional details (app name changed to "hen")Entitlements for main app$ codesign -d --entitlements :- hen.app Executable=/Applications/hen.app/Contents/MacOS/hen <?xml version="1.0" encoding="UTF-8"?> <!DOCTYPE plist PUBLIC "-//Apple//DTD PLIST 1.0//EN" "http://www.apple.com/DTDs/PropertyList-1.0.dtd"> <plist version="1.0"> <dict> <key>com.apple.application-identifier</key> <string>MRNTF77FCR.com.netsqllc.hen</string> <key>com.apple.developer.system-extension.install</key> <true/> <key>com.apple.developer.team-identifier</key> <string>MRNTF77FCR</string> <key>com.apple.security.files.user-selected.read-only</key> <true/> </dict> </plist>Entitlements for extensioncodesign -d --entitlements :- hen.app/Contents/Library/SystemExtensions/com.netsqllc.hen.henextension.systemextension/ Executable=/Applications/hen.app/Contents/Library/SystemExtensions/com.netsqllc.hen.henextension.systemextension/Contents/MacOS/com.netsqllc.hen.henextension <?xml version="1.0" encoding="UTF-8"?> <!DOCTYPE plist PUBLIC "-//Apple//DTD PLIST 1.0//EN" "http://www.apple.com/DTDs/PropertyList-1.0.dtd"> <plist version="1.0"> <dict> <key>com.apple.application-identifier</key> <string>MRNTF77FCR.com.netsqllc.hen.henextension</string> <key>com.apple.developer.endpoint-security.client</key> <true/> <key>com.apple.developer.team-identifier</key> <string>MRNTF77FCR</string> </dict> </plist>And console logallowing entitlement(s) for com.netsqllc.hen.henextension due to provisioning profile (isUPP: 1) Failed to open service: -536870174 Sandbox: com.netsqllc.hen(9915) System Policy: deny(1) system-privilege 1016The "Failed to open service" references /usr/lib/libEndpointSecurity.dylibAny help would be appreciated.

Holy cow, you were right!!I re-installed the app via the same package installer, before launching the application this time I followed your instructions for granting the extension full disk access, then launched the .app application and started the extension, and success!Thanks a million!

I have SIP enabled.I did all the initial endpoint development with SIP disabled and was launching a command-line version of the program via launchctl. Since re-enabling SIP I have been having to unlearn old habits/workflows and learning new ones.I had not seen the systemextensionsctl command before. I had mistakenly tried launchctl (which does show the extension running, but couldn't control the extension with the command).Whew, I am glad systemextensionsctl is there. I just wish I knew about it yesterday. :-)Thanks

Thanks!systemextensionsctl is exactly what I needed.I had been using launchctl which has worked fine when I was launching programs out of LaunchDaemons, but I hadn't known about systemextensionsctl.

Thanks on this (again)!I didn't realize I needed to disable SIP again to run the systemextensionsctl command. But now (I think) I have everything fixed, and I cleaned out the 386 extensions registered there! 😯

'The man page that this leads you to says for NSEndpointSecurityMachServiceName, "If set, this string will be the name of the MachService which can be used for XPC between the ES extension and its app."'I have not been able to find any refernce to "NSEndpointSecurityMachServiceName".Is this the equivalent of theNetworkExtension > NEMachServiceNamein the Info.plist file created for Network Extensions?Anyone have pointers to documentation for this?I am thinking this might be associated with the problem I raised in this post where I am trying to figure out how additional apps can connect to the EndpointSecurity extension: Secondary app connecting to endpoint extensionThanks,

Quick update:I duplicated my original endpoint project, stripped out the system extension, changed the Bundle ID, created a new Identifier and provisioning profile for the new Bundle ID, and, voila, I now have two independent programs connected to the endpoint extension.So, yes, independent applications can connect. Now I just need to figure out what detail I've missed in the other program. The devil is in the details.Here is how I am connecting (which works)let newConnection = NSXPCConnection(machServiceName: MachServiceName, options: .privileged) // set up interfaces and exported object newConnection.resume() let service = newConnection.remoteObjectProxyWithErrorHandler { error in ... } as? MiddleToLowerComm service?.establishConnection(message: "Hello") { }

Turns out my secondary app still had the sandbox turned on.I had to remove the app sandbox to get it to work. Apparently (?) even an independent application needs to have the sandbox removed to connect to the EndpointSecurity extension.Is there an exception I can add to the App Sandbox to allow it to connect to the ES extension? I'd prefer to have the Sandbox on if possible.