![]() So you really haven't solved the problem there. If the xpc passes Contacts info back the app, and network attackers compromise the app, then the network attackers have the Contacts info! The attackers may not have unlimited access to Contacts, but they still have some illicit access to Contacts. What's the attack vector? If you have network attackers, for instance, then of course they can't compromise an xpc that doesn't have network access. The service is given only AddressBook (Contacts) sandbox entitlement, so in case it ever gets compromised, no damage to user’s personal data could be done, as the service cannot access disks nor network.' This reasoning seems strange to me. On the other hand, here's what the GitFinder developers say: 'If an application needs access to contacts, it should not access them directly, but from a dedicated XPC service instead, passing required data back to the application. That's what the Apple documentation says. The reverse is also true: if the main executable accesses the Contacts API first, and the user grants permission, then the xpc service is automatically included in that permission. If the app has the Contacts hardened runtime entitlement, the xpc service accesses the Contacts API, and the user clicks 'OK' to grant access to Contacts, then the main executable will also be able to access the Contacts API without causing another user consent dialog to display. Moreover, user permission to access Contacts is granted to the app as a whole, including both the main executable and the xpc service, not to each separately. Likewise, if the main executable does not have the Contacts hardened runtime entitlement, then the xpc service will not be able to access the Contacts API, even if the xpc service has the Contacts entitlement. The hardened runtime entitlements of the embedded xpc are irrelevant, only the main executable matters. If the main executable has the hardened runtime enabled, and it has the Contacts hardened runtime entitlement, then both the main executable and the xpc service can access the Contacts API, regardless of whether the xpc service has the Contacts entitlement. For simplicity, let's set aside the sandbox for a moment and consider a non-sandboxed app with a non-sandboxed embedded xpc service. In contrast, the hardened runtime depends only on the main executable of the app. The sandbox allows the xpc service and the main executable to have different sandbox entitlements, which is how one can have the Contacts entitlement and the other not. Since they are independent, each operates according to its own separate rules. The sandbox and the hardened runtime are independent but overlapping technologies, as I explained in my earlier blog post.
0 Comments
Leave a Reply. |
AuthorWrite something about yourself. No need to be fancy, just an overview. ArchivesCategories |