Additional Info: The issue occurs only on ARM (Ventura and Monterey) not on Intel. XPC simply doesn't work after upgrading system extension on ARM. I tried to kill sysextd, nesessionmanager and other processes. Basically I'm trying to kill a process that manages XPC connections and info about processes and their signature validation (maybe it's somewhere deep in kernel and it's not possible to resolve it by this hack). It is possible that when trying to connect to XPC while starting our services in posinstall scirpt, installd hasn't quite yet completed and perhaps OS considers bundle signature not valid yet. Workaround is rebooting the machine, but we try to avoid that as much as possible. After reboot XPC works fine with upgraded system extension.

BTW does NSProvider.startSystemExtensionMode() need to be started from the main thread? Can it be started from a background thread that doesn't event use CFRunLoop, but a unix loop based on epoll? Does NSXPCListener has to be started from main thread?

That's right. Ideally we would mute the event. But simply checking a flag to determine that the file is sandboxed and handling it by es_respond_auth_result(client, message, ES_AUTH_RESULT_ALLOW, cache) would be sufficient. If it is a file our process running under root cannot access for scanning, then there is no reason to try opening it. When Installd unpacks app bundle into its sandbox, eventually it will move it into /Applications and it can be scanned there. The reason why we try to avoid opening files we cannot open is the fact that even the failure takes time. Even decision whther to use open() or access() has impact on how long the failure lasts. If the failure to open file takes 20ms, then for example an app with 50000 files could take 1000s or 16.6 minutes. Currently I'm strugling with determining whether to use access() or open() to check if the file can be accessed. There are cases where access() check is faster and cases where open() is faster (even if the result is failure) - it depends on various factors, like process has access to file, or doesn't have basic unix permissions or file is sandboxed. That's why I'm looking for ways to avoid unnecessary file system calls.

Boot sequence with user applications starting before Launch daemons and even system extensions clearly represents a potential security risk. It is very clearly visible when using FileVault. In this case user needs to enter password, OS decrypts volume and then it can startup and launch processes, but very quickly opens user's Desktop and starts to open applications. The bigest problem is that for example Endpoint system extension, which defends computer from infections or Network system extension, which scans network traffic and defends against infected web pages, email, etc. cannot immediately block harmful content. PIDs of these processes are larger than for example Launch Daemons. It means that for example Mail could open very quickly and load new message before Network System extension is loaded and traffic captured and scanned. We see it especaily on new OS versions running on ARM where it can take up to 10-30 seconds to properly load everything to protect users. That happens when OS is setup with FileVault and user has many, many applications opened - Mail, Calendar, Safari with lots of tabs, Teams, Remote Desktop, etc, etc. When user reboots computer, we clearly see this delay in start up of critical processes that should protect users, especially in corporate environment. Bootup sequence should look something like this: System Extenisons Launch Daemons Launch Agents User applications Is there a way to setup this sequence of process start up? Thanks, Robert

Well, it doesn't quite work with Distribution certificate, although I'm using exact same bundle id settings. The only difference between distribution and development entitlements is that System Extenion development prov.profile somehow contains following entitlement keycom.apple.developer.system-extension.install/key true/ which should only be present in the app bundle that registers extension, it should not be defined for system extension itself. In any case, it looks like this precise definition inlcuding keychain.access.group makes the error message "invalid application signature or incorrect provisioning profile" disappear: keyEntitlements/key dict keycom.apple.developer.system-extension.install/key true/ keycom.apple.developer.networking.networkextension/key array stringapp-proxy-provider/string stringcontent-filter-provider/string stringpacket-tunnel-provider/string stringdns-proxy/string stringdns-settings/string /array keycom.apple.application-identifier/key stringABCDEFGH.com.company.firewall.dev/string keykeychain-access-groups/key array stringABCDEFGH.*/string /array keycom.apple.developer.team-identifier/key stringABCDEFGH/string /dict with actual keychain value defined in the extesnion project settings as ABCDEFGH.com.company.firewall

Hi, I think I may have a solution for you. I was struggling with this for last several months (btw also using SecCodeCopySigningInformation), always getting back to investigate and never found a solution until now. It definitely isn't just a log noise, but a real signing problem, which could potentially block release though app store. First, some advice, which will save your time: You might find suggestions like using com.apple.developer.networking.multicast entitlement - doesn't work, you are able to build and sign system extension, but it crashes with signature error when OS tries to load it. Enabling Sandbox doesn't help either- but I definitely recommend enabling Sandbox for system extensions, you will need it for future release on App Store, if you plan it, and if you need to store/cache data, you can do it in protected group container with Sandbox on. It's worth the effort to Sandbox system extensions, although when pulishing notarized apps outside of App Store, it works without Sandbox. One of the 2 messages generated complains about applicaiton.group. Ignore that. If you need to communicate through XPC, you need app group anyway. You might find a suggestion to add keychain.access.group entitlement com.apple.token - forget it, it doesn't work with system extensions, you get a signing error when building. Although Apple's doc says com.apple.token is allowed by default, it is very likely tied to another entitlement, perhaps related to biometric reading. But keychain access group is actualy the culprit. SOLUTION: Define at least one keychain.access.group entitlement with your group ID in it, example: ABCDEFG.com.company.firewall keykeychain-access-groups/key array string$(TeamIdentifierPrefix)com.company.firewall/string /array If you do that, "invalid application signature or incorrect provisioning profile" log message will go away. Explanation: When creating bundle id, you cannot select/deselect keychain access group (there used to be a checkbox for this couple of years ago, if I remember). Provisioning profiles are now automaticlaly generated with keychain.access.group added, so you have to define it even though you don't need it. Regards, Robert

I see similar issue. When building binary, xcodebuild fails with signature error. I had to remove com.apple.token completely, although Apple's docs say it's allowed by default. Perhaps you need to use OurTeamId.com.apple.token.

Hi devfunshark, did you manage to fix this problem? I see the same thing when enabling Sandbox for System Extension target. SecCodeCopyGuestWithAttributes with kSecGuestAttributeAudit flag is failing with error code 100001 and I can see errors like MacOS error: -25337 and 67061 in console. If I try the same thing on App target which is also Sanboxed, it works. It's only the System Extension that's failing. I was thinking about creating a daemon which would run in the background and it would serve as a service for code signing verfication. System Extension would send audit token through XPC and daemon would do the app signature check and respond with result. Although it's probably another 0.1ms delay (well, maybe less) when comparing to doing that in System Extension with Sandbox disabled. Please let me know, if you found a better solution. Thanks, Robert