questions about EndpointSecurity & System Extension

1. Whether the EndpointSecurity Client must be a system extension?

My understanding is that EndpointSecurity require that clients run as root and have the entitlement, meaning there’s no specific requirement that the client be a system extension. This is in contrast to other subsystems, like system-wide NetworkExtensions, which must be packaged as system extensions.

Having said that, running as root is a significant hurdle. You wrote:

Then, build a simple app [it] works well on other machine which SIP is enabled. (Root permission & approved by TCC)

By definition an “simple app” isn’t running as root. In a real setup you’d need to install this as a launchd daemon in order to get root privileges, and that presents challenges for getting your entitlement. For a daemon to use the EndpointSecurity entitlement, it must be packaged in an app-like structure in order to have a place to store the provisioning profile that whitelists those entitlements.

All-in-all, it’s going to be easier if you just use a system extension.

2. If we must package Endpoint Security as a system extension, and be contained in an app. Whether the containing app can be distributed in Mac App Store?

That’s the plan. To quote WWDC 2019 Session 702 System Extensions and DriverKit:

Once you've packaged your System Extension into an app, you can distribute that app directly to your users using Developer ID or through the Mac App Store, which has never been possible with Kernel Extensions.

The above is misleading. Please see the clarification below.

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

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

Thank you Eskimo for your kindly help!

Hi eskimo

After some testing, I find if I enable sandbox for Endpoint Security in System Extension, the

es_new_client API return failed with ES_NEW_CLIENT_RESULT_ERR_NOT_PERMITTED.

Need I do something else?

Or if I don't enalbe sandbox for Endpoint Security in System Extesnion, can the App with none sandbox System Extension be submitted to App Store?

Do things actually work if you disable the App Sandbox?

can the App with none sandbox System Extension be submitted to App Store?

That’s more of a App Review policy question than a technical question, and thus not something that I can give a definitive answer on.

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

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

That’s more of a App Review policy question than a technical question, and thus not something that I can give a definitive answer on.

I ended up running this past the EndpointSecurity team and the current state of affairs is that EndpointSecurity system extensions cannot be deployed via the Mac App Store. This may change in the future, and if you have a specific business case for this I encourage you to file an enhancement request with those details.

Please post your bug number, just for the record.

I also want to be clear that the above is specific to EndpointSecurity system extensions. Other system extension types have other policies (hence the confusion in my earlier response). For example, right now NetworkExtension system extensions have the opposite problem, where you can’t deploy them via Developer ID (although we’re hoping to fix that sooner rather than later) (r. 54882466).

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

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

Hi eskimo

Thank you for your nice explain to make it clear.

But I also want to confirm about this:

For example, right now NetworkExtension system extensions have the opposite problem, where you can’t deploy them via Developer ID (although we’re hoping to fix that sooner rather than later) (r. 54882466).

Does it mean we must deploy NetworkExtension via Mac App Store now?

If so, may I get the detail or fix plan or fix process for r. 54882466?

(I didn't find that r. 54882466 on web site)

That may impact how we deploy our new product.

Thank you very much!

Does it mean we must deploy NetworkExtension via Mac App Store now?

Yes.

If so, may I get the detail or fix plan or fix process for r. 54882466?

No. As I mentioned above, we’re hoping to fix that sooner rather than later, but I can’t share anything more concrete than that.

Oh, one other thing. Fixing this should not involve any changes to the OS itself, but rather changes to the developer web site.

(I didn't find that r. 54882466 on web site)

Correct. Our bug reporting system only allows you to see bugs that you filed yourself, hence you can’t see this bug.

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

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

Hi eskimo,

Get it.

Thank you for your nice response.

I will montior the developer web site to get the latest status.

Thank you very much!

You wrote:

Then, build a simple app(no system extension) with EndpointSecurity.Framework

I have not found the "EndpointSecurity.Framework" in my Xcode list of libraries to link against. The closest I could find is libEndpointSecurity.tbd.

Am I missing framework components in my Xcode?

Thanks.

I have not found the "EndpointSecurity.Framework" in my Xcode list of libraries to link against. The closest I could find is

libEndpointSecurity.tbd

.

No. We often talk about EndpointSecurity as a framework but it’s not actually a framework. Rather, it’s a set of headers (everything under

/usr/include/EndpointSecurity/

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

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

Hi Eskimo,

we found another problem when we use the endpoint security system extension mach service for the XPC between ES system extension and its containing app.

The machService named as “$teamid.$es_bundle_id.xpc” which is reference “from https://forums.developer.apple.com/thread/118211 “.

We can create the connection in the client successfully. But when we try to use “remoteObjectProxyWithErrorHandler” get remote interface, it failed with the error message “Couldn’t communicate with a helper application.”

Even we add the same app group capabilities for the containing app and system extension, it report the same error message.

Till now, we found the only way to avoid the error: Remove the sandbox capabilities of the Containing App, the XPC will work well between Containing App and ES system extension.

==> If Apple support ES client distributed in Mac App Store, we may not avoid the issue by remove sandbox capabilities(when we try distribute in app store). Whether Apple will provide some solution about the XPC issue to some sandbox Conatining Apps?

If Apple support ES client distributed in Mac App Store, we may not avoid the issue by remove sandbox capabilities

Given that we don’t currently support EndpointSecurity system extensions in the Mac App Store, I’m reluctant to speculate about how that support will pan out when (and indeed if) it’s eventually added. My recommendation right now is that you target Developer ID distribution, in which case it’s fine to not enable the sandbox.

I must stress that the above is specific to EndpointSecurity system extensions. NetworkExtension provider system extensions do support the sandbox and they have a specific mechanism for handling IPC between the extension and the container app (namely

NEMachServiceName

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

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

Weichao, were you able to successfully use xpc to connect your client to your system extension? Has anyone been able to do this?

I have been trying to do the same thing, but get “Couldn’t communicate with a helper application.” during the call thru the remote proxy. I tried variations on the mach service name - "<teamid>.<bundle_id>.xpc" and "<bundle_id>.xpc" - but none worked. And I have app sandboxing off.

I had a chat with the system extension team about this. It seems that the

<TeamID>.<BundleID>.xpc

As to why you’re having problems, is your client running in a GUI login context (for example, an app)? If so, make sure you initialise your connection with

-initWithMachServiceName:options:

NSXPCConnectionPrivileged

options

Oh, if if you’re using the XPC C API, the equivalent is

XPC_CONNECTION_MACH_SERVICE_PRIVILEGED

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

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

right now NetworkExtension system extensions have the opposite problem, where you can’t deploy them via Developer ID

I have some good news on that front. It should now be possible to ship Developer ID signed NetworkExtension system extensions. Yay!

To get this working, you have to use a new set of NE entitlement values. For example, a Mac App Store transparent proxy uses the

app-proxy-provider

app-proxy-provider-systemextension

com.apple.developer.networking.networkextension

Note These entitlement values are understood by macOS 10.15 and later.

If you have an existing development signed NE sysex project, here’s how to change it over:

1. On the developer web site, create two new App IDs, one for the container app and one for the system extension embedded within that container.

2. Add the Network Extension capability to both App IDs.

3. Add the System Extension capability to the app’s App ID.

4. Add any other capabilities you need.

5. Create Developer ID profiles for both of these.

6. Download and import those profiles into Xcode.

7. In Xcode, configure your app and sysex targets to use manual code signing.

8. Then select the appropriate profile for each target.

9. Change the bundle IDs to match your new App IDs. This will require additional changes in your code, for example:

   • The product name of your system extension

   • Your code that sets the

     providerBundleIdentifier

     property.

   It’s best to do a search for the old bundle ID in order to make sure you got everything.

10. For both the app and the sysex, change your

    .entitlements

    file to use the new sysex variant of the entitlement. For example, if you’re creating a transparent proxy, you’d change

    app-proxy-provider

    to

    app-proxy-provider-systemextension

    .

    Note Xcode has not yet been updated to display a nice string for these (r. 58567937).

11. Build your app.

12. Install and test on a macOS 10.15 with SIP disabled.

    Note You only need to have SIP disabled if your app isn’t notarised. When you deploy to users, you notarise your app and that lifts the SIP requirement.

I just went through this process here in my office and it seems to work.

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

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