- a carefully groomed, public facing store monitored by apple (they have already)

- allow other app stores for non-monopolistic competition (eg: Amazon's android store)

- allow developers to use DRM on their apps

- allow app files to be loaded manually by the user

This distinction becomes important when you want to install that customization on a device for which the stock launcher is not open source but has been customized to fit with other apps, or simply when you want multiple customizations from different people.

However, if you insist on something a little more concrete: what if you want to add new buttons to the Android notification center, add new features to the status bar, or affect the behavior of the lock screen? These are not apps you can replace.

Can you tell me where you got this information? It would help in our attempts to mitigate misinformation: a lot of people say a lot of very wrong things about jailbreaking, and it is nice to fix the source.

* After installing OpenSSHd, obviously there is full access to the file system (at least as the "mobile" user, "root" may require a password). So at least this application is able to access more of the file system than a standard sandboxed application, right?

* At least one of the jailbreaks I tried caused iBooks to fail, and according to sources such as http://lumosdigital.com/blog/2011/02/15/apple-cripples-ibook... this is caused by an anti-jailbreak check that fails because sandbox restrictions are lifted

* I remember some drama (via twitter? irc? can't remember) about some .debs shipping with suspicious (setuid) files? (Probably from shady 3rd party repositories)

* None of the jailbreaks I've looked at has ever come with a technical description that explains their particular modifications.

* And finally, the fact that the jailbreak even works shows there are security measures being defeated in some capacity.

I'd love to be corrected on any or all of these points. :)

There are many processes, then, where there is no sandbox configured even on a stock iPhone. When you use Cydia (no sandbox) to install sshd (no sandbox) that is orthogonal to the behavior of other third-party applications that are still restricted to their sandboxes.

(As a quick aside on OpenSSH, as you mention that the root user "may" required a password: all users require passwords. However, the default password for both the mobile and root accounts is "alpine". If you install something like OpenSSH you should change these passwords.)

In the specific case of iBooks, the fairplay DRM checks are not checking that the sandboxes were damaged, but more generally that the system was jailbroken at all: the new checks verify that the kernel memory has not been modified by comparing hashes of critical code, and the old ones from this article that unsigned code runs (orthogonal to a sandbox).

Finally, the fact that the jailbreak works indicates that the pre-jailbroken system was insecure, not that the jailbroken system now has less security. In fact, for more serious exploits, the opposite is true: until Apple releases a patch, you should jailbreak to be safe.

As an example, the exploits that are launched from jailbreakme.com take advantage of bugs in the web browser (v1 attacked TIFF, v2 and v3 attacked TTF). These bugs were already there: any web page anywhere on the Internet could have used these to compromise MobileSafari.

Once in MobileSafari, bugs in the kernel are used that, again, were already there. These bugs could have been used by any code running on your system, including code running inside of a third-party App Store app (despite the sandbox) to jailbreak and possibly even rootkit your device.

However, once you were jailbroken, we offered (in all three of those cases; sometimes as packages and sometimes just by default as part of the process), patches to MobileSafari that would correct the ingress attack vector. Thereby, once jailbroken, you were protected from that exploit.

As to your separate (valid) point about jailbreaks not describing what they do, sadly the different jailbreaks that are available often use specific (as in, not shared; I'm failing to find the right word) kernel patches that are often even incompatible with each other (having different behavior).

Thereby, I can't tell you exactly what any specific jailbreak does. :( However, the overall game plan that they follow is fairly constant, and I can tell you what the "best practice" patches that jailbreaks install by default are in a short list here.

1) AFC2: allows you to access, over USB, all of / as root instead of just /var/mobile/Media as mobile. (Some people, including myself, do not like this patch; it is just an entry in a config file and is easy to remove.)

2) fstab / rw: makes / be mounted read-write. Normally the partition that holds the system software is read-only. As the files on this partition are owned by root, this does not affect the abilities of App Store applications (which run as mobile).

3) fstab /var suid dev: allows setuid executables and device nodes on the user data partition. You have to already have elevated permissions to create these files, so again this does not affect the abilities of App Store applications.

4) codesign: allow code that has not been signed by anyone to execute. This patch allows you to install code from third-party sources on your device, but does not affect the content you obtain from the App Store: they will only give you binaries that they have signed and verified.

5) codehash: allow processes with "corrupt" pages of code to execute. I disagree with this patch (and many jailbreaks do not include it), but it does not affect the abilities of App Store applications as they do not have write access to modify any executables.

6) rw->rx: supports changing a page of memory from writable to executable. Combined with earlier patches, this allows you to build JIT compilers, and is needed for Substrate's MSHookFunction to modify the behavior of a C function. This does affect all process security.

This sixth patch does not, as some people will claim, remove all the advantages of non-executable data or other stack protections. These pages still load as rw and are not executable: you cannot just overflow into them and then jump to them to execute their contents.

However, you can first re-mark the memory region as rx before jumping to it. To do so would require a return-to-libc attack. However, if you already know enough about the target process to do a return-to-libc you may as well just do a return-oriented-programming attack.

It also should be noted that even if you consider the return-to-libc followed by the jump to the now-executable region to be a security hazard, it must be noted that there could be any manner of non-memory security-related mistakes in the App Store applications you have installed.

I will thereby argue that you are really, in the end, relying on the application sandboxes to provide security: the App Store developer probably left tons of gaping holes in their code, and may have even included an entire interpreter-VM... this patch does not increase the magnitude of an attack, only the probability.

7) rwx: allows memory to be marked for write and execute at the same time. This is dangerous, conceptually, but it is required for high-performance JITs. Otherwise, you find yourself having to flip the page from write to execute back constantly, which has performance and safety ramifications.

Applications that choose to mark their pages rwx will end up with lowered security with this patch. However, such processes are normally virtual machines that have numerous other security mitigation strategies, and should therefore, in the end, be much safer than stricter native applications.

However, I will argue that this patch does not offer an attacker anything over the sixth patch: to attack a normal process you will still need to use mmap/mprotect to manually get some rwx pages, at which point you already have return-to-libc and probably just need rx, not rwx.

8) sandbox: allow processes to access files that are outside of their sandbox based on Unix permissions rather than the normal sandbox rules. This affects the security of App Store applications, but there is much more nuance to it.

This, then, is the last and most important patch to our discussion. In some jailbreaks this patch sucks: it literally just turns off the sandbox entirely. You can normally tell that this happened because nothing works ;P (the sandboxes also mediate shared keychain access).

Most jailbreaks instead make targeted modifications to the sandbox restrictions. The "best practice" that I laid out for this patch a while back (and which planetbeing and comex both implemented for various jailbreaks, and which I believe is being used in redsn0w and Absinthe currently) is:

"Add an exception that if a file being accessed is not stored in /var/mobile (the user's home directory) then rather than do not have the sandbox intercept or affect the access check: allow the normal Unix permissions to (probably deny) the access."

This allows you to get read access to files stored on the system permission (not write access, as that would require root). It also allows developers to specifically create scratch storage that is writable by mobile (if they need) somewhere on the filesystem.

While I can come up with some theoretical reasons why there might be a security risk in having read access to files that, thanks to any single person having jailbroken their device, anyone can just download from the Internet anyway, I consider this a far and difficult stretch.

Instead, I will argue that all of the important data is stored in the user's home directory (/var/mobile), and that the parts of the sandbox that "work for the user" protect the files in that folder, while the other parts of the sandbox are more "working for Apple".

(This is detectable because if you install some extensions, such as "file:// for MobileSafari", you can get Safari to read from static web pages stored anywhere on the filesystem but your home directory. This causes a lot of confusion to some people, as that is an obvious place to put things ;P.)

So, AFAIK, none of the major jailbreaks that you find deactivate the sandbox on these personal files. When developers really consider the ability to access these files important, they build daemons (running in the background outside of sandboxes) to mediate access.

Hopefully this goes to some length to help you with your concerns (and I guess I'll now go tell Britta that I wrote this, so she can use content from it or refer people to it as required in the future). I'd still love to get better references for where you see random misinformation ;P.

(edit: I just thought of another patch that is included. 9) crazeles: a ludicrously complicated hack by planetbeing that neuters the FairPlay DRM checks that cause iBooks to refuse to operate correctly on jailbroken devices. This specifically addresses the earlier paragraph on iBooks.)

I had the general idea that the sandbox was probably working out of some complicated rulesets a la SElinux (which I also do not know in detail, unfortunately).

To clarify a few of my original mis-conceptions:

* For the iBooks DRM, one of the JB tests was apparently to drop an (incorrectly signed?) exexutable and try to exec() it, if it runs, the sandbox is "no good". Out of this; I assumed (some) jailbreaks would therefore allow any App Store app to go crazy exec()ing (since iBooks comes from the App Store), which feels like a security problem

* I wasn't aware that jailbreaks still maintained a sandbox for AppStore apps, while bypassing it for non-AppStore apps. I assume installing .debs from cydia is the equivalent of handing the .deb author a root shell. (OpenSSH comes from a .deb, for example)

* I wasn't aware whether keychains and other private data was protected after a jailbreak. Could apps go snooping on other app data, for example to pick up credentials/session cookies from Facebook.app, read stored mail, access the photo roll without the location permission prompt, etc. Only non-AppStore apps?

In other words, does it boil down to:

* You can still install AppStore apps without worry, they only run within their own context? (I am guessing: mostly yes, but if apple were evil they could do the iBook DRM trick, post back your UDID to apple and ban your device)

* You should exercise extreme caution with any .deb, since that's equivalent to handing out a root shell to the author (even just for a moment - .deb preinst scripts etc?)

Thanks again for taking time to explain all the details so far. (You really should just copy&paste this into a section of your cydia website! :) )

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.

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!]

Far too many geeks have this innate delusion that people are like them. That they care about side loading apps, open source freedom, other browser rendering engines, jail breaking etc. Most people just see this as introducing complexity and unnecessary choices.

Perhaps the problem is in how these are articulated.