Have upgraded to Ventura 13.6 but behavior is still the same. Has anyone run into this ?

Thank you @eskimo I do not see a crash report & I am pretty sure Network Extension gets initialized correctly since it works after approving the initial prompts (SysExt + Network Ext). This happens when you disable network extension using System Settings --> Network --> Filters Let me follow steps in Debugging a Network Extension Provider link above & will post what I see when is Enable/ Disable Network Filter. Also, I am using the same notarized build on macOS Sonoma 14.0 & I am able to correctly Enable/Disable via System Settings --> Network --> Filters, so that makes me thing if its confined to Ventura ?

I added logs to SystemExtension main as well as overrode init of FilterDataProvider, this is what i see 2023-10-31 15:19:14.128731-0700 0x169df Debug 0x0 9550 0 com.***.***.net: [scwx:netext] D Main P:09550 T:2080 "first flight " [main.mm:14] 2023-10-31 15:19:14.135417-0700 0x16a0d Debug 0x0 9550 0 com.xxxx.xxxx.net: [scwx:netext] D Main P:09550 T:7000 "FilterDataProvider init" [FilterDataProvider.mm:121] 2023-10-31 15:19:14.136349-0700 0x16a0d Debug 0x0 9550 0 com.xxxx.xxxx.net: [scwx:netext] D Main P:09550 T:7000 "IPC init start event listener" [FilterDataProvider.mm:138] ... [Hit disable via System Settings --> Network --> Filters] 2023-10-31 15:21:11.797161-0700 0x16e11 Debug 0x0 9550 0 com.xxxx.xxxx.net: [scwx:netext] D NetExt P:09550 T:f000 "stopFilterWithReason" 1 [FilterDataProvider.mm:196] .... [Hit enable via System Settings --> Network --> Filters] After this nothing happens, I do not see network extension being initialized

Yes I can confirm on Ventura, if you reinstall the network extension, its status goes back to green. We ran into this mainly because of a customer issue they were seeing on their box. @eskimo : Is this bug being actively worked on & is a fix expected in future version of Ventura ? Do we need to file a feedback/radar for it ?

Created feedback request FB13702329 (API query for SIP Protected Paths) to track this.

@Dmytro_cpp : I was looking at https://book.hacktricks.xyz/macos-hardening/macos-security-and-privilege-escalation/macos-security-protections/macos-sip which suggests looking at "/System/Library/Sandbox/rootless.conf" to figure out SIP protected areas. But not sure if format of conf file is defined somewhere & might be subject to change in future releases

@DTS Engineer Output of vtool command on macOS 11.7.10 /Applications/SecureworksTaegis.app/Contents/MacOS/com.secureworks.agent.daemon.app/Contents/MacOS/com.secureworks.agent.daemon (architecture x86_64): Load command 10 cmd LC_BUILD_VERSION cmdsize 32 platform MACOS minos 11.0 sdk 14.2 ntools 1 tool LD version 907.0 Load command 11 cmd LC_SOURCE_VERSION cmdsize 16 version 0.0 /Applications/SecureworksTaegis.app/Contents/MacOS/com.secureworks.agent.daemon.app/Contents/MacOS/com.secureworks.agent.daemon (architecture arm64): Load command 10 cmd LC_BUILD_VERSION cmdsize 32 platform MACOS minos 11.0 sdk 14.2 ntools 1 tool LD version 907.0 Load command 11 cmd LC_SOURCE_VERSION cmdsize 16 version 0.0

Thanks for the analysis. That really helps, actually the symbol was referenced from one of the third party libs we are using. Will try to see if we can move away from the current version of the lib