2 ms·

My understanding is Apple’s notarization is about accountability than policy/approval: I’m okay with having my apps stamped with my legal identity - that’s no d

My understanding is Apple’s notarization is about accountability than policy/approval: I’m okay with having my apps stamped with my legal identity - that’s no different to Microsoft AuthentiCode going right-back to the late-1990s.

kmeisthax 3y ago
Regardless of how much review is used, Apple will still be gating what entitlements can be used by third-party apps. They already do this for dev-signed apps - i.e. you can't provision apps that ask for things like, say, task_for_pid-allow[0]. There's actually a whole host of entitlements that you either can't get as a third-party developer, or have to ask for special permission[1] for, or are only available to paid Apple Developer Program members. Whether or not this hampers your use of private APIs depends on whether or not the API requires a private entitlement in order to work. There's a lot of stuff that doesn't - notably, all of IOKit is there just sitting in the public Frameworks directory, but you won't pass App Review if you touch any of it, because that's still considered private API surface. If you want to touch private APIs that are gated behind a private entitlement, you're not getting them. Remember: most of iOS's security comes from sandboxing, not human review. In fact, there's been a lot of scams on iOS that App Review has failed to catch. So Apple is never, not in a million years, going to give an official way to break out of the sandbox. [0] In XNU, processes are part of a Mach task. The task_for_pid syscall obtains a Mach port for a given process's Mach task. If you have this port, you have full control over the process. As you can imagine, this syscall normally only works for development processes that have opted-in to debugging with the get-task-allow entitlement. task_for_pid-allow bypasses this, allowing you to debug everything on the system. Some jailbreaks will even patch this syscall to allow retrieving a task for PID 0 - i.e. the kernel. [1] Notably, there is an entitlement for using the VP9 decoder, which only Google gets to use.

kmeisthax 3y ago

Regardless of how much review is used, Apple will still be gating what entitlements can be used by third-party apps. They already do this for dev-signed apps - i.e. you can't provision apps that ask for things like, say, task_for_pid-allow[0]. There's actually a whole host of entitlements that you either can't get as a third-party developer, or have to ask for special permission[1] for, or are only available to paid Apple Developer Program members. Whether or not this hampers your use of private APIs depends on whether or not the API requires a private entitlement in order to work. There's a lot of stuff that doesn't - notably, all of IOKit is there just sitting in the public Frameworks directory, but you won't pass App Review if you touch any of it, because that's still considered private API surface. If you want to touch private APIs that are gated behind a private entitlement, you're not getting them. Remember: most of iOS's security comes from sandboxing, not human review. In fact, there's been a lot of scams on iOS that App Review has failed to catch. So Apple is never, not in a million years, going to give an official way to break out of the sandbox. [0] In XNU, processes are part of a Mach task. The task_for_pid syscall obtains a Mach port for a given process's Mach task. If you have this port, you have full control over the process. As you can imagine, this syscall normally only works for development processes that have opted-in to debugging with the get-task-allow entitlement. task_for_pid-allow bypasses this, allowing you to debug everything on the system. Some jailbreaks will even patch this syscall to allow retrieving a task for PID 0 - i.e. the kernel. [1] Notably, there is an entitlement for using the VP9 decoder, which only Google gets to use.