sysextd: "no policy, cannot allow apps outside /Applications" - NEFilterDataProvider system extension on macOS 26

App & System Services Networking
gbiondo OP
Created 1w
Replies 2
Boosts 0
Views 54
Participants 2

I'm developing a macOS security tool using NEFilterDataProvider as a system extension. On macOS 26 beta (25E241), sysextd consistently rejects my extension with:

sysextd: no policy, cannot allow apps outside /Applications

Configuration:

  • App installed in /Applications/
  • Signed with Developer ID Application (693DSH8GN5)
  • Entitlement: com.apple.developer.networking.networkextension = content-filter-provider
  • com.apple.developer.system-extension.install = true
  • Developer Mode enabled on test machine

Comparison with Little Snitch:

Little Snitch runs correctly on the same machine. Key differences I found:

  • Little Snitch uses content-filter-provider-systemextension instead of content-filter-provider
  • Little Snitch has com.apple.security.app-sandbox = false
  • Both signed with Developer ID Application

When I switch to content-filter-provider-systemextension, Xcode rejects every provisioning profile because none match that entitlement value, and the Developer Portal doesn't expose fine-grained control over the Network Extensions array values.

Questions

  1. Is content-filter-provider-systemextension the correct entitlement for system extensions on macOS 26?
  2. How should the provisioning profile be configured to support it?
  3. Is there a known sysextd issue on macOS 26 beta causing this regardless of configuration?
  4. Is there - somewhere! - a guide on how to build such an extension?

Thanks in advance for your help.

Answered by DTS Engineer in 881751022

It sounds like you’re using Developer ID signing for day-to-day development. That’s a mistake on multiple levels. I talk about this in general in The Care and Feeding of Developer ID, but there are extra issues with system extensions, where system policy requires that Developer ID signed sysexen be notarised.

So my advice in this case.

  • Use Apple Development code signing for day-to-day development.
  • Use Developer ID for pre-release testing and distribution.

There are a couple of key benefits with this approach:

  • It lets you build and debug without enabling development mode, which is a big win IMO.
  • Xcode’s automatic code signing works well with Apple Development signing.

Even if you’re not using Xcode, you can create a small test project in Xcode, get it working, and then follow the same path it took. See Debugging a Network Extension Provider for specific advice on how to bring up a provider in Xcode.

One thing that Xcode doesn’t handle is the -systemextension suffix )-: To learn more about that, read Exporting a Developer ID Network Extension.

Finally, you wrote:

On macOS 26 beta (25E241)

If possible, try to avoid developing on a beta release. Rather, developer with production versions of macOS and Xcode, and then test what you’ve built on both production releases and on our beta seeds.

I think that’ll be enough to get you up and running, but please write back here if you hit any snags.

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

Replies  2
Boosts  0
Views  54
Participants  2
gbiondo OP
1w

Update: After inspecting all provisioning profiles on our system, we found that:

Profiles generated for development and Developer ID distribution contain content-filter-provider Profiles generated via Direct Distribution contain only packet-tunnel-provider-systemextension and app-proxy-provider-systemextension No profile contains content-filter-provider-systemextension

When we set content-filter-provider-systemextension in the entitlements file (matching Little Snitch's configuration), Xcode rejects all available profiles with a mismatch error. This means the Developer Portal does not appear to generate provisioning profiles with content-filter-provider-systemextension for content filter system extensions. Is this a portal issue, or is there a different provisioning mechanism required?

0
DTS Engineer OP
Apple
5d
Recommended

It sounds like you’re using Developer ID signing for day-to-day development. That’s a mistake on multiple levels. I talk about this in general in The Care and Feeding of Developer ID, but there are extra issues with system extensions, where system policy requires that Developer ID signed sysexen be notarised.

So my advice in this case.

  • Use Apple Development code signing for day-to-day development.
  • Use Developer ID for pre-release testing and distribution.

There are a couple of key benefits with this approach:

  • It lets you build and debug without enabling development mode, which is a big win IMO.
  • Xcode’s automatic code signing works well with Apple Development signing.

Even if you’re not using Xcode, you can create a small test project in Xcode, get it working, and then follow the same path it took. See Debugging a Network Extension Provider for specific advice on how to bring up a provider in Xcode.

One thing that Xcode doesn’t handle is the -systemextension suffix )-: To learn more about that, read Exporting a Developer ID Network Extension.

Finally, you wrote:

On macOS 26 beta (25E241)

If possible, try to avoid developing on a beta release. Rather, developer with production versions of macOS and Xcode, and then test what you’ve built on both production releases and on our beta seeds.

I think that’ll be enough to get you up and running, but please write back here if you hit any snags.

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

1
sysextd: "no policy, cannot allow apps outside /Applications" - NEFilterDataProvider system extension on macOS 26
First post date Last post date
 
 
Q