questions about EndpointSecurity & System Extension

Hi,


We have some questions about the EndpointSecurity Frameworks.


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

We use the es-client entitlements making a develop provisonprofile with its EndpointSecurity-client capabilities. Then, build a simple app(no system extension) with EndpointSecurity.Framework and the provisonprofile. It works well on other machine which SIP is enabled. (Root permission & approved by TCC )

So, whether it means that we can distribute the EndpointSecurity-Client as a simple app(without 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?

Up vote post of weichao119 Down vote post of weichao119
15k views
Posted by
weichao119
Reply
Add a Comment

Apple Recommended

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
value, while a Developer ID product should use 
app-proxy-provider-systemextension
. The full list of these is documented on the 
com.apple.developer.networking.networkextension
entitlement page.

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:

    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"
Posted by
eskimo
Post not yet marked as solved Up vote reply of eskimo Down vote reply of eskimo
Post marked as Apple Recommended
Add a Comment

Replies

is it possible to make that post with the developer ID details the accepted answer?

No. Only the thread originator can change the accepted answer.

What I can do is mark it as Apple Recommended (-:

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

Posted by
eskimo
Post not yet marked as solved Up vote reply of eskimo Down vote reply of eskimo
Add a Comment