I had just noticed, in passing through the open tab to the link you provided, that I had not adequately explained the old iBooks-on-4.2 check. I added some clarification, and then saw that in fact you had noticed the issue now in this reply as well ;P.
It seems that Corona (the iOS 5.0.1 untether), at least, does allow an App Store application to call exec(). I am honestly not certain why that is allowed... I am, however, also not entirely certain whether that is normally disallowed: it might actually not be considered a problem by Apple.
The reason why I point out that there might actually not normally be a restriction against exec() is that I just tested using fork() on my iOS 5.0.1 iPhone 4S using Corona (Absinthe 0.4) and, in fact, you can't call that from an App Store application. (So, the sandbox works. ;P)
To test, I ran Facebook, then used `cycript -p Facebook` to inject a console into that process (using cycript, my JavaScript/Objective-C hybrid shell). I then ran `new Functor(dlsym(RTLD_DEFAULT, "fork"), "v")()` to get a reference to and call the fork system call stub from libSystem (libc).
The sandbox daemon was then asked by the kernel to verify whether that process was allowed to fork, and as it was not I got the following log message and the process was denied. (I say "denied" as it was not killed: it just got -1 from fork() with EPERM.)
Jun 18 15:00:16 Transponder sandboxd[768]: Facebook(759) deny process-fork
Moving on, your comparison to SELinux is, AFAIK, fairly accurate; on Ubuntu, AppArmor is also a similar system to the Apple sandbox (and, transitively, SELinux). It should be pointed out, however, that these systems are also per-process: I can still install things on the computer and mark them "no limits".
As for your other comments, App Store applications on jailbroken devices still cannot snoop into your keychain, mail, or the data stored for other applications such as Facebook. They do have access to your camera roll, but that is true of non-jailbroken devices as well (this is fixed on iOS 6).
Finally, you are correct in that installing a .deb on your system is handing the packager the equivalent of a temporary root shell on your device: in addition to installing arbitrary code with the package (the point of installing it at all), it gets to actually run scripts as root during the (un)installation itself.
Neat! Thanks again for the super-detailed clarifications!
Going back to my comment that started this sub-thread, I guess the point then still stands, "Too bad there's no way to side-load unsigned (or signed by a custom CA) apps while still maintaining the sandbox restrictions." (i.e. no "safe thirdparty appstores") ;)
[quick note on the camera roll thing, I think apps are denied access before the user confirms a location permission popup]
[another quick note on the exec() thing, exec() probably wouldn't work since appstore codesign only works on a single binary. probably related to why only static libraries are allowed, too]
[edit: the fork/exec thing may also be tied in to the strict limitations on background processing for appstore apps? interesting to see your cycript experiment there!]
Interesting! I had assumed that if you could mark pages of memory as executable (for a JIT), that an app could use that to call all sorts of security/privacy sensitive private APIs they're usually forbidden from using. But maybe not? Or is iOS sandboxing just good enough it doesn't matter? (but at the minimum, it does still seem to nullify the app store review process if apps can introduce arbitrary new behavior/code after review)
More exactly, the kernel does provide a way for applications to mark memory pages as executable (which is exactly what Safari does, after all), but you need to have the right permissions to use the API, and App Store apps don't have those permissions...
a-Shell – runs WASI binaries (via Apple's native out-of-process runtime, so it even gets to JIT, I believe!) and comes with a C compiler, as well as Python: https://apps.apple.com/us/app/a-shell/id1473805438
But yeah, sure these are all somehow self-contained in a way that a DOS emulator can't possibly be in a way only App Store reviewers are enlightened enough to grasp.
This is a design issue that is basically unsolvable unless Apple fully rethinks the iOS security model. In the current model, you can't give a library separate permissions than the process in which it was loaded - that's the gist of it. This has nothing whatsoever to do with Security as Gruber is spinning it to be - not directly at the least. As with Flash the real reason seems to be bypassing control.
I suspect RIM's security model allows them to do package / API specific permissions and prevent the app from doing things such as mmap(... PROT_EXEC) - anyone familiar with BB Security/Permissions model - care to comment?
Blame Apple for being incompetent with permissions for OS X applications. They only have "App Store with a single set of sandbox limitations" and "non-App Store downloads with no restrictions". Where is the middle ground? Why not have fine-tuned permissions to grant a specific application access to the APIs it needs?
How hard is it to pop a modal operating system dialog saying "Application X wants to be able to monitor running processes?" It's not. Apple has simply failed to find the middle ground.
But you cant run any code you want. You’re still in a restrictive sandbox, and you still need to explicitly request the limited expansions to the permissions scope that the OS allows the user to grant you - neither of which is dependent on the App Store.
What's so bad about calling private APIs? I get why Apple doesn't want it, but as a user I don't care.
The sandbox prevents apps from pulling in native code over the network. The OS won't allow pages to be marked as executable unless the code is signed by Apple.
Apple's refusal to support XPC and the ability for apps to launch secondary processes is the real underlying issue here. Being able to separate out execution and process permissions from the main app solves a ton of third-party SDK issues as well as just normal "why is my app crashing because of decoding?"-style issues.
Notably on iOS there's no good way to isolate unsafe native libraries from the rest of your app without violating app store policies, because Apple enforces apps to be single process and doesn't allow use of its own sandboxing apis.
I still have hopes that Apple cares enough and finds a way to whitelist the JSC lib somehow.
Not sure exactly how that would work, because permissions to allocate executable memory is given per process on iOS. But I guess they could inspect the call stack to see if the allocating call indeed comes from the built-in JSC lib?
It seems that Corona (the iOS 5.0.1 untether), at least, does allow an App Store application to call exec(). I am honestly not certain why that is allowed... I am, however, also not entirely certain whether that is normally disallowed: it might actually not be considered a problem by Apple.
The reason why I point out that there might actually not normally be a restriction against exec() is that I just tested using fork() on my iOS 5.0.1 iPhone 4S using Corona (Absinthe 0.4) and, in fact, you can't call that from an App Store application. (So, the sandbox works. ;P)
To test, I ran Facebook, then used `cycript -p Facebook` to inject a console into that process (using cycript, my JavaScript/Objective-C hybrid shell). I then ran `new Functor(dlsym(RTLD_DEFAULT, "fork"), "v")()` to get a reference to and call the fork system call stub from libSystem (libc).
The sandbox daemon was then asked by the kernel to verify whether that process was allowed to fork, and as it was not I got the following log message and the process was denied. (I say "denied" as it was not killed: it just got -1 from fork() with EPERM.)
Jun 18 15:00:16 Transponder sandboxd[768]: Facebook(759) deny process-fork
Moving on, your comparison to SELinux is, AFAIK, fairly accurate; on Ubuntu, AppArmor is also a similar system to the Apple sandbox (and, transitively, SELinux). It should be pointed out, however, that these systems are also per-process: I can still install things on the computer and mark them "no limits".
As for your other comments, App Store applications on jailbroken devices still cannot snoop into your keychain, mail, or the data stored for other applications such as Facebook. They do have access to your camera roll, but that is true of non-jailbroken devices as well (this is fixed on iOS 6).
Finally, you are correct in that installing a .deb on your system is handing the packager the equivalent of a temporary root shell on your device: in addition to installing arbitrary code with the package (the point of installing it at all), it gets to actually run scripts as root during the (un)installation itself.
reply