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
ameydalvi
Users receive reputation points by contributing quality content to the forums.
Posts include post and replies published on the forums.
Post authors can mark replies as Accepted to indicate successful solutions.
Apple Developer Forums admins can mark replies as Apple Recommended to indicate an approved solution
Post
Replies
Boosts
Views
Activity
@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
@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
Created feedback request FB13702329 (API query for SIP Protected Paths) to track this.
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 ?
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
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 ?
Have upgraded to Ventura 13.6 but behavior is still the same.
Has anyone run into this ?