questions about EndpointSecurity & System Extension

Question

weichao119 OP

Created Nov ’19

Replies 46

Boosts 0

Views 16k

Participants 12

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?

Answered by DTS Engineer in 402187022

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:

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.
Add the Network Extension capability to both App IDs.
Add the System Extension capability to the app’s App ID.
Add any other capabilities you need.
Create Developer ID profiles for both of these.
Download and import those profiles into Xcode.
In Xcode, configure your app and sysex targets to use manual code signing.
Then select the appropriate profile for each target.
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.
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).
Build your app.
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"

Boost

Answer 1

dknecht OP

Jan ’20

Is it possible to have a network extension work in both Mojave and Catalina?

Also followed instructiona above and still getting on the network extension in the console:
Signature check failed: code failed to satisfy specified code requirement(s)

neagent Signature is valid and has the correct designated requirement

neagent Provider is signed with a Developer ID certificate

neagent Rejecting app extension provider REDACTED.macos.worker because it is signed with a Developer ID certificate

0

Answer 2

kevinh456 OP

Jan ’20

I just followed these instructions can report the exactly same error messages from neagent and my extension.

0

Answer 3

DTS Engineer OP

Apple

Jan ’20

Is it possible to have a network extension work in both Mojave and Catalina?

No. The

***-systemextension

entitlements are only supported on 10.15 and later. Then again, support for system extensions was introduced in 10.15.

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

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

0

Answer 4

futuremind OP

Jan ’20

Any hints on the error?

neagent Signature is valid and has the correct designated requirement

neagent Provider is signed with a Developer ID certificate

neagent Rejecting app extension provider BUNDLEID because it is signed with a Developer ID certificate

Seeing the same thing.

0

Answer 5

DTS Engineer OP

Apple

Jan ’20

Seeing the same thing.

On what OS version?

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

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

0

Answer 6

dknecht OP

Jan ’20

I am seeing it with 10.15.3 (beta) and i believe was also tested on 10.15.2.

0

Answer 7

DTS Engineer OP

Apple

Jan ’20

I am seeing it with 10.15.3 (beta) and i believe was also tested on 10.15.2.

OK, cool. It’s just that earlier you mentioned 10.14, and this is not going to work there.

I tested a Developer ID signed NE system extension on 10.15 and it worked for me (and I’ve no reason to believe that this has been broken in one of the 10.15.x updates). The instructions I posted on 14 Jan were based on that test.

Does your NE system extension work if you don’t use Developer ID signing, that is, you sign it with an Apple Development signing identity?

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

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

0

Answer 8

dknecht OP

Jan ’20

Before making the changes it worked with Apple Development signing identity. Now if we use Apple Development signing identity app with new profile the main app won't launch either. Do we need to use different profile for Apple Development signing identity without ***-systemextension? Or can we use same profile and just have different entitlement file?

Any other ideas to get Developer ID working?

0

Answer 9

kevinh456 OP

Jan ’20

How critical is the need to create new app ids? If I delete and readd the old bundle id, will it work? I distribute my updates via Sparkle and can't change the bundle id.

0

Answer 10

DTS Engineer OP

Apple

Jan ’20

Or can we use same profile and just have different entitlement file?

I think that’ll work [1]. It’s easy to test though. Build the Apple Development and Developer ID variants of your app and then dump the entitlements:

% codesign -d --entilements :- /path/to/your/code

and the profile:

% security cms -D -i /path/to/your/code/Contents/embedded.provisionprofile

You have to make sure that the contents of

com.apple.developer.networking.networkextension

in the profile covers all the entitlements you claim in your code signature.

Oh, and make sure you do this twice, once for the app and again for the NE provider sysex embedded within your app.

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

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

[1] On a modern Xcode. Prior to Xcode 10, it probably wouldn’t have.

0

Answer 11

dknecht OP

Jan ’20

We are still seeing this and we tried everything. There was a post removed that seemed to show why this wold never work. Did you test with packet-tunnel or just app-proxy?

neagent Rejecting app extension provider BUNDLE because it is signed with a Developer ID certificate

0

Answer 12

futuremind OP

Jan ’20

I did everything as described by eskimo one more time, from scratch.

I've been trying with the previously existing app and sysex IDs we had by just regenerating the provisioning profiles after modifying app entitlements and it didn't work. Now I tried using freshly generated ones, still seeing the same issue.

"neagent Rejecting app extension provider REDACTED.macos2.worker because it is signed with a Developer ID certificate"

So what I have now is this:

1. App

The code signature contains entitlements.

Sandbox entitlements:

User-selected files, read access: YES.

Allow outgoing network connections: YES.

Team identifier: “[TEAM]”.

Application groups: “group.[ID]”.

Application identifier: “[TEAM].[ID].macos2”.

Other entitlements:

keychain-access-groups: “[TEAM].keychain.[ID]”.

com.apple.developer.system-extension.install: YES.

com.apple.developer.networking.networkextension: “packet-tunnel-provider-systemextension”.

2. Sysex

The code signature contains entitlements.

Sandbox entitlements:

Allow outgoing network connections: YES.

Team identifier: “[TEAM]”.

Allow incoming network connections: YES.

Application groups: “group.[ID]”.

Application identifier: “[TEAM].[ID].macos2.worker”.

Other entitlements:

keychain-access-groups: “[TEAM].keychain.[ID]”.

com.apple.developer.networking.networkextension: “packet-tunnel-provider-systemextension”.

Are these entitlements OK?

I also verified that the profile has all com.apple.developer.networking.networkextension entitlements listed for both App and Sysex:

Profile:

<key>Entitlements</key>

<dict>

<key>com.apple.developer.networking.networkextension</key>

<array>

<string>packet-tunnel-provider-systemextension</string>

<string>app-proxy-provider-systemextension</string>

<string>content-filter-provider-systemextension</string>

<string>dns-proxy-systemextension</string>

</array>

Code signature claimed entitlements:

<key>com.apple.developer.networking.networkextension</key>

<array>

<string>packet-tunnel-provider-systemextension</string>

</array>

0

Answer 13

DTS Engineer OP

Apple

Jan ’20

Did you test with packet-tunnel or just app-proxy?

I tested with transparent proxy. I’d be quite surprised if there were broken for other provider types, but anything is possible. At this point I’m going to recommend that you open a DTS tech support incident so I can look at this in detail. Or, if you’re sure you’ve got it right, simple file a bug (in which case, please post your bug number, just for the record).

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

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

0

Answer 14

DTS Engineer OP

Apple

Feb ’20

I had a chat with the system extension team about this. It seems that the
<TeamID>.<BundleID>.xpc
Mach service was specifically added to allow your clients to communicate with an XPC service vended by your system extension.

As a follow-up to this, check out the discussion of 57244148 in the macOS Catalina 10.15.4 Beta Release Notes.

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

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

0

Answer 15

mdolan OP

Feb ’20

Hi Quinn,

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." Since this is no longer a LaunchDaemon app with a plist that has mach services, will this work the same and let any application connect to the ES extension via XPC? We have multiple apps that need to connect to our driver and if it's only the enclosing app that this allows, well, that'll not be good.

This is on my plate to work on again next week, and it'd be nice to know before I head down a dead end.

Thanks

0