Hardened Runtime relaxation entitlements disallowed on System Extensions

You say the container has JIT related feature, so you add a com.apple.security.cs.allow-jit entitlement, or something similar. But you say that the error message is about Hardened Runtime relaxation entitlements disallowed on System Extensions.

Did you apply the entitlement to the container, or the extension?

this is on the container, it also has systemextension.install & networkextension entitlement following the FiltertingNetworkTraffic example

Hi, there is some updates, after I remove networkextension entitlement:

<key>com.apple.developer.networking.networkextension</key>
<array>
  <string>content-filter-provider-systemextension</string>
</array>

I got the application opened. But when I try to activate the network extension, I got this error message:

Failed to save configuration Duolingo English Test: Error Domain=NEConfigurationErrorDomain Code=10 "permission denied" UserInfo={NSLocalizedDescription=permission denied}
-[NEFilterManager saveToPreferencesWithCompletionHandler:]_block_invoke_3: failed to save the new configuration: Error Domain=NEFilterErrorDomain Code=5 "permission denied" UserInfo={NSLocalizedDescription=permission denied}

From this doc, I think I shouldn't exclude the networkextesion entitlement, but if I include it, it seems that it will be treated as a System Extension? Is there any workaround?

When you embed an NE provider within an app, both the app and the NE provider (appex or sysex) must claim the com.apple.developer.networking.networkextension entitlement.

if I include it, it seems that it will be treated as a System Extension?

No. The most likely cause of problems like this is that the NE entitlement is restricted, meaning that it must be authorised by an embedded provisioning profile. Xcode will do that for you automatically [1], but if you’re using third-party tools you only get the support that they provide [2].

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

[1] Modulo the issue described in Exporting a Developer ID Network Extension.

[2] Which, based on the questions I see here, is nothing )-: That means that you have to do it yourself. If you find yourself in that position, see:

• Creating distribution-signed code for macOS

• Packaging Mac software for distribution

I‘ve embedded the provision profile and double checked the final app content.

And I am able to open the app if I either remove the JIT entitlements or the networkextension entitlements (of course both of them will have other issue)

I am now currently trying to move the networkextension out to a xpcservices, is this the right direction?

Unfortunately, using the XPCServices to invoke NEFilterManager method didn't work

Is this a macOS bug, you can check the error, it treat /Applications/APPName.app/Contents/MacOS/APPName as a system extension & require the entitlement to not to include any hardened runtime relaxation elements?

mac_vnode_check_signature: /Applications/APPName.app/Contents/MacOS/APPName: code signature validation failed fatally: When validating /Applications/APPName.app/Contents/MacOS/APPName:
  Hardened Runtime relaxation entitlements disallowed on System Extensions

OK, I figured it out. com.apple.security.cs.allow-jitis OK to be kept. After I remove this entitlement, everything works

    <key>com.apple.security.cs.allow-unsigned-executable-memory</key>
    <true/>

Right.

These three hardened runtime entitlements form a hierarchy:

• com.apple.security.cs.allow-jit
• com.apple.security.cs.allow-unsigned-executable-memory
• com.apple.security.cs.disable-executable-page-protection

You only ever need one of them, because the latter ones subsume the earlier ones [1]. However, the earlier ones offer better protection, and thus it’s best to stick with them if you can. And in the case of a sysex, the only the first is allowed.

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

[1] On Intel. Things are slightly different on Apple silicon, where the last two are effectively the same.