Hello, we are working on a feature that sometimes needs to drop/postpone DNS requests except for requests for allowed domains or originating from allowed executables. In this product we already have a network extension Socket Filter present. We were looking for correct technology to use for this purpose. 1), socket filter can not be used, as it is not possible to selectively drop only some UDP packets. If we block one flow, the socket can no longer be used to communicate with the specific remote IP and fails with EPIPE. This leads to DNS resolving issues as not every software can cope with UDP not working for part of the remote servers (AFAIK including Apple's own mDNSresponder). 2), loading socket filter drops all active connections. This is understandable for firewall type API, but it is an extremely inconvenient behavior if we do not want to actually implement a firewall. There is currently no option to configure this behavior of socket filter. 3), using DNS proxy is not really feasible, as it is not a transparent proxy and only a single DNS proxy can run at any given time. In case of multiple registered DNS proxies only the last one stays running. It is also a pretty heavyweight solution for what we want to accomplish. We tried using BSD pf packet filter with user specific rules: "pass out quick from any to any keep state user nameofuser" but 4) this breaks if DNS proxy is present. Attribution of proxied flows is not visible to BSD pf packet filter which sees all traffic as attributed to the DNS proxy instead of the original process. This has been reported as working as intended by Apple. The only other solution seems to be a packet level filter. But here we hit other issues: 5), since order of processing is Socket Filter —> DNS proxy -> VPN -> packet filter, we can not guarantee all traffic will be filtered (packet filter does not see at least some VPN traffic on MacOS, did not test this with all VPN types though...) 6). the NEFilterPacketProvider does not seem to have a way how to attribute the packet to a process. While the NEPacket obtained via delayCurrentPacket() has a metadata member, it seems to be never present on MacOS (at least on Monterey). This prevents per app/process/binary filtering and leaves only packet content inspection as an option. While it may in theory be possible to use Socket Filter to attribute packet level addresses to processes, it seems pretty cumbersome and potentially fragile in case DNS proxy is used. 7), there is an issue with coexistence of Packet and Socket filter. It seems that any change of NEFilterManager’s configuration concerning packet filter causes brief stop and start of socket filter as well. This is extremely inconvenient because a socket filter reload subsequently leads to the drop of all connections on the system. Please note that the packet filter does not cause such drop of connections on loading, so it would be ideal for our purpose. The only workaround is to have multiple system extensions, which is actually a correct engineering approach, but that leads to a horrible user experience. Allowing multiple system extensions is far from streamlined for the average user, and he would need to also allow one filter after each other separately. If we were to use socket filter, DNS proxy, VPN and packet filter in a single product, which ideally should each reside in standalone system extensions for resilience, the user would need to allow 8 separate dialogs!! And adding feature during lifetime of the product should not lead to repeated requests to allow system extensions; this is a nightmare from administration point of view. It should really be a once per app action (at least the load of system extension). But we are getting sidetracked. Coexistence seems like the most feasible user centric solution, but it is not really possible with the combination of Socket and Packet filters. Am I missing something or is the only possible solution to use Packet Filter extension (a second one, to not interfere with the Socket Filter one) and filtering based on packet content, which only works for wifi/ethernet interfaces?

On Big Sur, user interaction is sometimes necessary to modify trust settings of a certificate (see https://developer.apple.com/documentation/macos-release-notes/macos-big-sur-11_0_1-release-notes#Security). This means that sometimes, app calling SecTrustSettingsSetTrustSettings blocks until user enters password even if it is running as root (or fails with "The authorization was denied since no user interaction was possible" if it is run from a context where user session is not available). But it seems that for vast majority of machines, entering the password is not necessary (for other voice confirming this, please see https://developer.apple.com/forums/thread/671582). Please is there any way how to check whether user interaction will be required for this operation on the machine in advance? Be it via api or some characteristics of the system? This would lead to better user experience of our app...

I am trying to write non-system extension EndpointSecurity client. As recommended by “eskimo”, I have made an app in xcode, gutting it so that main runs the ES client.However I do not know how to add EndpointSecurity entitlement. In December we have received a mail from Apple notifying us that we can now use this entitlement. In the attached email, there was a description how to add the entitlement to provisioning profile: “When you create a Development or Distribution provisioning profile for your Bundle ID, you'll be prompted to select additional entitlements. Click Profiles on the sidebar, then click the Add button in the upper-left corner. Choose a provisioning profile type and follow the prompts until you see ‘Additional Entitlements.’ Select the Endpoint entitlement from the dropdown to include the Endpoint Security entitlements in your new profile. Click Continue to finish the process.” This seems out of date; there does not seem to be a way how to add entitlements when generating provisioning profile. I can see System Extension and Network Extension entitlements when setting up app id, however even there the EndpointSecurity entitlement is not present.Surprisingly, I am able to sign the app with a provisioning profile that does not contain ES client entitlement (I have thought it would fail, as the profile is supposed to be a whitelist of entitlements), and the app itself seems to have the entitlement:$ codesign -d --entitlements :- com.whatever.test.app/contains key com.apple.developer.endpoint-security.client set as truehowever trying to run this unsurprisingly fails (i guess now the profile is applied?):taskgated-helper: com.whatever.test: Unsatisfied entitlements: com.apple.developer.endpoint-security.clienttaskgated-helper: Disallowing: com.whatever.testamfid: /path/to/com.whatever.test.app/Contents/MacOS/com.whatever.test signature not valid: -67671kernel: proc 73552: load code signature error 4 for file "com.whatever.test"Please anyone knows what should be done to add the Endpoint Security client entitlement to an app?