#Gitfox review full#

'What if the main executable crashes?' is not an interesting question, because if the main executable crashes, it's game over for the xpc services too. This is clear if we think in terms of stability rather than privilege separation. 'What if the main executable gets compromised?' is the wrong question in the context of embedded xpc services. The goal of the xpc service is not to limit the damage the app can do if it's compromised, the goal is to prevent the app from getting compromised in the first place. The GitFinder developers worry that the 'completely unnecessary sandbox entitlement defined for the application only increases chances of damages, as the application, being bigger and more complicated, is much easier target for security attacks than tiny dedicated XPC service is.' Again, I think this is kind of backwards. There's not much compromise risk inherent to making those API calls. Contacts API access is not dangerous in itself, because the Contacts info already on disk is presumably not maliciously crafted. The data that comes over the network may be maliciously crafted by an attacker. Network access is dangerous, which is why you may want to strictly sandbox it. One of the purposes of an xpc service is to do 'dangerous' operations inside the service.

#Gitfox review full#

That's a full solution to protecting Contacts. (This is the architecture of Apple's own apps such as Safari.) If network attackers compromise the xpc service, then the attackers can't access Contacts at all, because the xpc service would be very strictly sandboxed. For true protection, you want the network access in the xpc service, and the Contacts entitlement in the main app. This architecture seems to be the opposite of what you'd want. 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.