3 ms·

But that's its job! open() would be a much simpler syscall if it didn't bother to enforce access controls. The code would be a lot easier to maintain too...

tptacek 11y ago
I'm not sure I understand your argument. Because there is already some complexity in the kernel, we should be fine with adding more complexity to it?
- joosters 11y ago
  It could use many of the existing access control methods already in the kernel. No extra kernel complexity required. e.g. the advertising ID could be stored in a file with appropriate permissions. All the API needs to do is open the file and read it out.
mikeash 11y ago
It is not the runtime's job. It is the kernel's job, but the whole point of private API is that they're within the same process and don't require a syscall to invoke. Calls which require kernel involvement that you're not supposed to be able to call already have access control mechanisms so you can't call them.
- joosters 11y ago
  Well yes, I meant it's the kernel's job. If the information is already in-process, then there's no access control at all and an app could just read it directly, rather than calling a private API. I think we're talking at cross-purposes. My original question was why Apple don't restrict this restricted information. It appears we both agree that putting it behind an access control (like a syscall) would prevent this.
  - mikeash 11y ago
    Right. It's confusing in a discussion about private API in general, because private API is pretty much by definition calls with no access control which are merely undocumented. Thus saying that Apple should be more clever about prohibiting private API calls is weird. But if it's just one particular call that needs better enforcement, yeah, they should do that. And it will involve promoting it beyond "private API."
  - bsder 11y ago
    > My original question was why Apple don't restrict this restricted information. Because Apple wants to use this information, but they don't want anybody else to use this information. If Apple requires security permission to get at the information, then they hose themselves as well.
- NateLawson 11y ago
  You're both right. It's the kernel's job to ultimately enforce this policy, and calling private APIs should only be a compatibility problem, not a security risk. I believe the current sandbox design makes it more complex to promote system interfaces to require individual access control. It doesn't provide the fine-grained access, so more work is needed to separate code with the granularity that sandbox policies can control it. This does happen over time (e.g. UDID in iOS 8).
  - mikeash 11y ago
    In what way is the sandbox not fine grained? I thought the whole idea with entitlements was that access to individual facilities could be controlled separately.

tptacek 11y ago

I'm not sure I understand your argument. Because there is already some complexity in the kernel, we should be fine with adding more complexity to it?

joosters 11y ago
It could use many of the existing access control methods already in the kernel. No extra kernel complexity required. e.g. the advertising ID could be stored in a file with appropriate permissions. All the API needs to do is open the file and read it out.

mikeash 11y ago

It is not the runtime's job. It is the kernel's job, but the whole point of private API is that they're within the same process and don't require a syscall to invoke. Calls which require kernel involvement that you're not supposed to be able to call already have access control mechanisms so you can't call them.

joosters 11y ago
Well yes, I meant it's the kernel's job. If the information is already in-process, then there's no access control at all and an app could just read it directly, rather than calling a private API. I think we're talking at cross-purposes. My original question was why Apple don't restrict this restricted information. It appears we both agree that putting it behind an access control (like a syscall) would prevent this.
- mikeash 11y ago
  Right. It's confusing in a discussion about private API in general, because private API is pretty much by definition calls with no access control which are merely undocumented. Thus saying that Apple should be more clever about prohibiting private API calls is weird. But if it's just one particular call that needs better enforcement, yeah, they should do that. And it will involve promoting it beyond "private API."
- bsder 11y ago
  > My original question was why Apple don't restrict this restricted information. Because Apple wants to use this information, but they don't want anybody else to use this information. If Apple requires security permission to get at the information, then they hose themselves as well.
NateLawson 11y ago
You're both right. It's the kernel's job to ultimately enforce this policy, and calling private APIs should only be a compatibility problem, not a security risk. I believe the current sandbox design makes it more complex to promote system interfaces to require individual access control. It doesn't provide the fine-grained access, so more work is needed to separate code with the granularity that sandbox policies can control it. This does happen over time (e.g. UDID in iOS 8).
- mikeash 11y ago
  In what way is the sandbox not fine grained? I thought the whole idea with entitlements was that access to individual facilities could be controlled separately.