Well the exploit is the bypassing or patching of iOS checkpoints via BootROM exploit or Userland exploit to gain root access to the file system which then allows the download of Cydia apps. Then Cydia tweaks and themes can work because the checkpoints have been patched or bypassed (depending on the exploit method). These non-iTunes apps don't need a signature/key because the JB bypasses or patches the iOS signature check. So the exploit really is the BootROM or Userland exploit.
Anyway the Peachpit book says
/Users/kevin/Library/Containers/com.apple.mail/Data/Library/Preferences/com.apple.mail.plist
The test answer I have says
B. ~/Library/Preferences/ (this is incorrect)
I develop for iOS but have never sandboxed an app. Looking at the Apple Developer docs.
So as I suspected it is sort of a trick question when they use the word user. It's irrelevant if it's user or not, there is no other location to store prefs for a sandboxed app other than ~/Library/Containers/
That's what I get from the Apple docs and PeachPit book.
Which is the correct answer. You do not want to have any sandboxed app writing any data, including preferences, outside of its container. If the container is the jail, then by simply being able to write preferences outside of the container, you have already effectively broken out of the jail.
Say you have downloaded an app that does such a thing. And also say that because you haven't looked at the actual preferences being written, you don't realize that it's a shell script that writes data from /dev/zero or /dev/random to your home directory.
The next time you run the app, the app checks for the existence of that file, and if it exists, changes permissions of the file and executes it, filling up your entire filesystem. Or better than that, say that it checks for agents for it to launch, and since it is in your context, will set them to start the next time your mac starts, plus continues to write /dev/zero to your home directory.
Not only would you have filled up the filesystem, but cause resource intensive services to run that you didn't want to have running to begin with; all because a sandboxed app was able to write data outside of its container.
That is the reason why all of it needs to be contained within its container; application data, preferences, the executable, the entire lot.
BL.