Post

Replies

Boosts

Views

Activity

System Extension deactivationRequest fails with error "The operation couldn’t be completed. (OSSystemExtensionErrorDomain error 13.)"
We have a main app that handles UI and interaction with the user. And we also have daemon contained inside of it. Daemon has all the business logic and FDA and root permissions. Now we want to add a network extension. First we added the Network Extension to Main app and it was working fine (to test the waters). But then we decided to move it to Daemon since it has all the business logic and NE mostly contains business logic and no UI. It needs to be there. Now NE activationRequest(forExtensionWithIdentifier is working fine. But deactivationRequest(forExtensionWithIdentifier: during uninstall always fails with this error System Extension deactivationRequest fails with error he operation couldn’t be completed. (OSSystemExtensionErrorDomain error 13.) OSSystemExtensionError Code 13 says "An error code that indicates the system was unable to obtain the proper authorization." What does this actually mean. Also if there is an error why is it throwing it during uninstall rather than install? To make it more clear this is our app structure is Main.app -> Contents -> Mac OS -> Daemon.app -> Contents -> Library -> SystemExtensions -> System Extension Bundle Apple doc says @discussion This method creates a new request to activate/deactivate a System Extension. Extensions are discovered from the `Contents/Library/SystemExtensions` directory of the main application bundle. Our System Extension is present on the main app bundle and has Contents/Library/SystemExtensions structure but one extra layer deep. Is this supported app structure?. If not is there any way to succesfully uninstall NE from code. Right now systemextensionsctl uninstall won't work without System Integrity Protection disabled. Keeping NE on the main app will break our project structure and require major rewrite of the app. Also whenever I run systemextensionsctl with SIP on I get this message At this time, this tool cannot be used if System Integrity Protection is enabled. This limitation will be removed in the near future. Please remember to re-enable System Integrity Protection! Apple introduced System Extensions in 2019. It is still not there yet. Does anybody have any idea when will Apple make it work? if at all?
2
0
776
Apr ’24
Does an app need Full Disk Access if System Integrity Protection is disabled?
I am going through the list of ways to check if my app is given Full Disk Access (FDA) or not. Out of which only one method is supported by apple. @note The only supported way to check if an application is properly TCC authorized for Full Disk Access * is to call es_new_client and handling ES_NEW_CLIENT_RESULT_ERR_NOT_PERMITTED in a way appropriate * to your application. I have implemented this method using EndpointSecurity and calling it from a root process as required. But when I disable System Integrity Protection (SIP) and call it, it succeeds without FDA. No error is thrown. Then I tested, in our app both EndpointSecurity and protected folder access (like Documents folder) functionalities are working fine even without FDA when SIP is disabled. Now my questions are When SIP disabled, does every app has FDA access by default?. Is there any use case that still needs FDA access when SIP is off?. Is there any way to check for FDA permission given or not whenever SIP is off, since above method won't work in that case?.
1
0
429
May ’24