macOS content filter: supported denial guarantee across provider failure for a bounded process tree

We are designing a bounded local macOS operation with a supervisor, controller and helper. All three must be unable to cause prohibited network effects, including attributable delegated requests, before admission and until quiescence. Unrelated applications must retain their normal network access. We are seeking an API contract clarification, not reporting a reproduced OS bug. No NetworkExtension provider has been activated for this design.

Our reviewed SDK is MacOSX27.0.sdk; its presence is not a runtime qualification. Please identify the supported macOS versions for your answer. The design must tolerate provider crash, termination, disconnection and unresponsiveness, and operation lease expiry/revocation. Administrative filter disablement or privileged reconfiguration is a separate unresolved threat-model case, not something we assume ordinary failure handling covers.

We reviewed content-filter deployment in TN3134 and the nullable/delegated audit tokens in NEFilterFlow. We understand that NEURLFilterManager.shouldFailClosed concerns URL-filter decisions, not an established guarantee for arbitrary content-filter traffic. EndpointSecurity AUTH deadlines are also a separate mechanism. The VPN routing article documents dropping during specific transitions, but has system exceptions; TN3120 excludes using a packet tunnel as a dropping content filter. We therefore have not adopted that workaround.

  1. For macOS NEFilterDataProvider / NEFilterPacketProvider, is there a supported configuration that keeps prohibited operation traffic denied when the provider crashes, is killed, disconnects, hangs or cannot deliver a decision? Please distinguish new flows, existing/previously permitted flows, queued data, restart intervals, and configuration disable/removal.
  2. What supported admission and teardown guarantees allow releasing the first protected process only after enforcement is effective, then retaining denial through lease revocation and shutdown? An enabled configuration alone would not demonstrate that barrier.
  3. How should this guarantee cover operation-caused DNS and delegated system-service traffic, including absent/ambiguous audit tokens, without denying unrelated host traffic? If content filters cannot meet that scope, can App Sandbox without network entitlements provide the independent denial boundary for these roles, and what documented exclusions or additional constraints apply?

A reference to the supported contract, or a precise statement of the requirement that needs to change, would let us select an architecture before implementing and activating a native provider. We are not requesting private APIs or an unsupported packet-tunnel filter.

Are you trying to simple deny network access? Or mediate network access? That is, do you want to disallow everything? Or allow some connections but block others?

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

Thank you, Quinn. For the bounded offline operation in this question, the requirement is to deny all network access, rather than selectively allow or inspect destinations. The scope is the operation's supervisor, controller and helper, including network requests attributable to them through delegated system services. Unrelated applications on the Mac should retain their normal network access. The restriction must apply before releasing any of these processes and remain effective until the processes and attributable delegated work are quiescent. In particular, a filtering-provider crash, disconnect, hang or restart must not open a temporary network-access window. Does that clarification point to a supported macOS mechanism for this scope, including whether individually sandboxing the roles without network entitlements provides the needed independent boundary? We are asking about a supported design; we have not established or claimed that our current implementation provides this guarantee.

the requirement is to deny all network access

Have you thoughts about achieving that by enabling App Sandbox? That is, have your top-level process enabled App Sandbox (claim com.apple.security.app-sandbox) and then not enable networking (that is, claim neither com.apple.security.network.client nor com.apple.security.network.server).

This might be easier because blocking networking at the NE level requires you to accurately track responsibility, which can be quite challenging.

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

macOS content filter: supported denial guarantee across provider failure for a bounded process tree
 
 
Q