Endpoint Security app launchable from launchd/xcode, not from command line

We have an application that has the endpoint security entitlement. We recently got access to sign with this permission, and are operating on a machine with SIP enabled for the first time. TCC has been granted for the application, and it can run from XCode/launchd without issue so long as the scheme is edited to run as root.


Oddly, though whenver I try to run from a root shell, I get a failure of `ES_NEW_CLIENT_RESULT_ERR_NOT_PERMITTED` on my call to `es_new_client`, and the following error is printed in the console:


Sandbox: agentnm(2312) System Policy: deny(1) system-privilege 1016


Any advise on why this might not be runnable from the command line, but is runnable from both the xcode launcher and launchd?

Replies

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’m not 100% sure what’s going on here but problems like this are not uncommon on macOS. macOS has a bunch of execution context above and beyond the UNIX-y stuff that

sudo
is aware of. Creating a ‘root shell’ via
sudo
puts your code in a mixed execution context, where the UNIX-y stuff, like your UID, is root but the Mac stuff is inherited from the GUI session. It’s not uncommon for APIs that depend on the Mac stuff to behave strangely in this context.

If you want more background on this, check out Technote 2083 Daemons and Agents. It’s an old un but a good un.

Share and Enjoy

Quinn “The Eskimo!”
Apple Developer Relations, Developer Technical Support, Core OS/Hardware

let myEmail = "eskimo" + "1" + "@apple.com"

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.

Hi, I'm jumping on this same cart, with the same error, only in my case I'm in even earlier stage of getting into Endpoint Security --- All I try to do is to build and run the related Apple Sample code as is! It's the "SampleEndpointApp" sample project.

In my case, upon receiving from Apple the e-mail granting us the entitlement needed, I went on to create a development provisioning profile for this, and I'm trying to sign the app (and related System Extension) using that.

The strange thing is - I see in the sample logs that the system extension was registered and installed - and I see lots of log lines that confirm that the system extension is actually being loaded from some place in the SIP protected parts of the OS.

Only there's then an endless stream of error log lines for my App/Extension - nearly every 2-3 seconds another bunch of errors.

About half of the error lines are coming from the Sandbox (similar to those the OP is complaining about)

and the rest from the actual system extension - basically claiming:

error 12:35:04.919059+0200 com.mycompany.mac.prevention.Extension Failed to open service: -536870174
error 12:35:04.919128+0200 com.mycompanty.mac.prevention.Extension Failed to create the ES client: 4

I really need a little light or guidance on this... I haven't even scratched the surface, and already stuck.

only in my case I'm in even earlier stage of getting into Endpoint
Security

While this has similar symptoms, it’s more likely due to a packaging problem with your project. Check that:
  • You have SIP disabled. Without this you’ll have to notarise your code before you can test it.

  • Your container app has the com.apple.developer.system-extension.install entitlement set to true (more on this below).

  • This entitlement is in the allowlist in the container app’s provisioning profile (more on this below).

  • Your ES sysex has the com.apple.developer.endpoint-security.client entitlement set to true.

  • This entitlement is in the allowlist in the ES sysex’s provisioning profile.

When you check for the presence of an entitlement, dump the built binary rather than relying on the .entitlements file. To do this:

Code Block
% codesign -d --entitlements :- /path/to/your/code


Remember that you need to run this twice, one for the container app and once for the sysex embedded within that container app.

To check the provisioning profile’s allowlist, do this:

Code Block
% security cms -D -i /path/to/embedded.provisionprofile


Again, you need to do this twice, for the profile embedded in the container app and again for the profile embedded in the sysex (which is, in turn, embedded within the container app).

Share and Enjoy

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