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

There is a very good reason why you cannot get App notarized with free Apple Developer account. When you setup Apple Developer account you can build apps and even run them on another Mac, use certian entitlements (not all though). That's good for developers who wish to become familiar with the platform. You can even distribute your app, but when another user starts your app, gatekeeper will present a warning that this app is from unidentified developer. You can still go to System Preferences -> Security and allow the app to load, but users generally should never do that, unless they really don't care what happens on their machine. When the app is notarized, macOS displays a prompt "Apple checked this app for malicious content and found no problem with this app" (or some text like that). User can click "Open" to instantly start the app. Now imagine how much malware, spyware and other types of harmful apps are out there and how many people try to exploit users' trust. Gatekeeper prevents apps from unidentified developers to load for very good reason. If anyone could get app notarized, than bad guys could build an app that doesn't look suspicious, but after a year could start misbehaving. It's something that's very diffcult to catch even for Apple, no one really has enough time to disassemble apps and go instruction by instruction to verify what apps really do. If app causes damage, it may be difficult to get the author to answer for his crime. You can create free developer acount online, easily and with any email address and you can pretty much make up mailing address, you don't have to fill up billing info. This allows anyone to learn software development, even someone who cannot afford pay for development tools, so it's open to anyone, students, kids, people from countries with worse economic conditions. On the other hand bad guy can use fake identity and cause harm. Then it would be impossible to trace him. When you pay for Apple Developer account, you create a tracable financial transaction. These days it's not easy to open bank account without verification of identity. So if the bad guy distributes app to other people and casues damage to user or to Apple servers, authorities can trace him pretty much anywhere in the world, you can get court order and bank would have to reveal identity of the account holder. Although not all countries would cooperate in such investigations and countries with lower moral standards probably wouldn't even care if one of their citizens managed to sell users' data or managed to make money from ransomwere from people who trusted their apps, but it's definitely getting harder for bad guys to avoid consequences. More and more countries cannot afford to ignore international relationships and law&order. Another question is if the price for paid Apple Development membership should be $99 or $0.99. But again bad guy could have his/her developer account closed, but for $0.99 he could create 100 paid accounts and cause damage. $99 is low enough if developer really wants to create legitimate app and distribute to users, and at the same time, it is enough to discourage bad guys paying for multiple accounts that could be revoked 1 by 1 in case of misbehavior. Today's operating systems are more secure and it is partially thanks to app signing and verification of developer's identity. I remember in the old days I encountered 2 viruses: In around 1992 Yenkee Doodle virus which copied itself into ever executable on machines running MSDOS. It was easy to cleanup using antivirus, but still anoying. In 2002 or 2003 there was an interesting virus called MS Blast. I had an official Windows XP SP1 cd and after installation I connected to my internet service provider and bang! a popup with "Your machine will restart in 60s, 59, 58..." showed up. There was nothing you could do and machine rebooted and repeated the process. That happened actually without opening browser or doing anything else. Just a clean OS and connecting to Internet service provider who had their servers infected.

Filed a bug https://feedbackassistant.apple.com/feedback/7827478

I will definitely file a bug, because today we found that even having the app in a separate instance in DerivedData (when having cloned yet another instance of repository and building the same project with Xcode from the second location) the mac security appears to check wrong location and not the one, which we launched. It's possible that when allowing extension to load for the first time, the system simply rememebers that location and always checks that despite running a new instance from a different location. Most surprising was that moving app bundle to Trash didn't fix the problem. The system probably fixes the links to point to Trash. We had to empty the Trash to finally get the system to check signature of the extension in the bundle we were running.

BTW isn't it a security risk, if the extension is being checked in /Applications folder instead of the location where the app actually starts? What if a rougue app is downloaded from the internet for example to Downloads folder and is allowed by user to run? If the app uses the same bundle id as a legitimate security app (perhasp it could, if it's not released through app store and is not notarized), is macOS going to check the signature of the app or it's extension in /Applications folder?

Another dev said, it started working correctly and popup now shows App name when he builds and signs the app. However it stopped working for me after I removed copy of the app from /Applications folder. I investigated and found the following: When running the app from Debug folder (build by Xcode in DerivedData), the popup shows "(null)" instead of the app name. When I copy the app to /Applications, then the popup shows up correct app name. When I leave the app in /Applications, but run the instance from Debug folder, it shows correct app name. So it looks like macOS popup probably gets the correct app name only if the app with the same bundle id is present in the /Applications folder. That's the case even if you start the app from a completely different location and the app is signed by another developer (dev still must be part of the same team), macOS security looks for the app in /Applications folder. It very likely also checks signature there, because some logs related to signature errors disappeared (if I was looking correctly). You can completely clean up your app in DerivedData, delete filter configuration from System Preferences -> Network, you can completely clean up System Extesnions, yet when building the app and running from Debug folder (running directly from Xcode) the macOS popup shows correct app name as long as another copy (even very old build) exists in /Applications folder. Removing the app from /Applications folder then breaks the popup again. Obviously users are not going to keep deleting filter configuration and they must run apps with extensions from /Application folder, so it's not an issue with officially released apps in real-world setup, but you see what developers have to go through and how much time they waste on issues like this one (several days in fact, not to mentioned guys who tried to test if it works on their machine).

Filed a new bug https://feedbackassistant.apple.com/feedback/7758784

It looks like it fixed itself for me and the popup now shows name of the app instead of (null). Although other devs still see this when they build the project. If I give them my build and they run it on their machines, the app also shows correct app name in the popup. It's something with their development provisioning profile. We are on the same team and using the same bundle ids, so Xcode should be able to sign the app the same way. I'm thinking that perhaps by changing some project settings, like app group id and reverting back, I triggered regenertion of provisioning profile and that may have fixed it for me. But so far nothing fixes it for other devs - clearing extensions, clearing dervied data, tweaking project settings, rebooting machine, rebuilding. We are on the same Xcode version 11.5. Not sure if DTS ticket can help, if it now works for me, but not for others.

Yes. I'm using virtual machine. Although we are not restoring it all the time, I use clean up steps for extensions:systemextesnionsctl uninstall <TeamId> <BundleId>systemextesnionsctl resetSometimes, to quickly test the popup, I just go to System Preferences -> Network and delete my filter configuration.It should simply verify bundle signature. Although I'm using developer certificate, dev.cert worked with SimpleFirewall sample and it could display correctly the app name.Even completely deleting DerivedData does not help.

Hi,did you check app.group entitlement? It's needed for IPC communication.You need to set it for both, app and the extension, to the same value, eg. <TeamId>.com.(companyName).(productName)When editing entitlements on Apple portal, you will see that it adds "group." into app group id and you cannot change it, so leave it as is and use "group.com.(companyName).(productName)". The group will be replaced in provisioning profile by team id.Make sure in Xcode you have following entitlements enabled:App target:- Network Extension- System ExtensionSystem Extension target:- Network ExtensionMake sure NSMachServiceName com.(companyName).(productName).simpleFirewallExtension matches to bundle id of the system extension target.There could be other potential issues. If you are sending data (objects) through a protocol function you wrote, it requires that all classes are derived from NSObject and implement NSSecureCoding protocol. If any property or referenced object anywhere in the hierarchy does not fulfill those criteria, you will receive precisely the error you described. Just today I had to write bunch of unit tests to verify encoding/decoding, because I was receiving "Couldn’t communicate with a helper application".The problem is that app doesn't provide much info in Xcode debug view. You can also check Console app, where you will also see what system extension logs. You might find errors, like extension dropped connection and stack trace with decoding errors.But there are many more potential problems. You may need to resolve them step by step.Regards,Robert