I had just published my previous post about Mountain Lion and Gatekeeper when Apple announced the third postponement of the sandboxing deadline for the Mac App Store, this time until June.
This was expected; given the announcements and the changes in the sandbox details (including some unannounced ones which I can’t comment on), a postponement was inevitable. In fact, my hunch is that at WWDC 2012 a final postponement will be announced, to coincide with the golden master of 10.8; or, at the very least, 10.7.4 will be back-fitted with the same Gatekeeper and sandboxing capabilities. This latter option has a potential pitfall; Xcode doesn’t like applications setting their minimum system version to a point release.
A brief recap of the sandbox is in order. If the developer turns on sandboxing, the application will run inside a protected environment. The user’s home folder is substituted by a per-application container where parts of the original home are reflected by symbolic links. Certain folders, such as ~/Library and ~/Documents, are not reflected. A sandboxed application’s system calls are closely monitored and restricted. The intention is that the application cannot interact with other applications, or with other app’s documents – not even with their preferences. However, some parts of the file system can always be read, basically to allow the application to use system resources.
These restrictions can be selectively eased either by a signaled user intention or by a list of so-called “entitlements” set into the application signature. Entitlements can allow access to iCloud, to selected hardware such as networks, cameras or printers, to user databases such as calendar or address book, or to parts of the file system outside of the application container such as music, picture or movie folders. Access to files can be granted as read-only or read-write.
User intentions can be signaled by actions such as dragging & dropping icons from the Finder onto the application’s icon or windows, or by selecting files/folders from the standard open or save panels (and there are entitlements for that option). This opens a temporary breach in the sandbox for that run; starting with 10.7.3, this access permission can be stored into a bookmark file for later use by the application.
Temporary exemptions can be granted to allow the application permanent access to any part of the file system, however Apple advises that such exemptions may not be allowed for apps in the Mac App Store.
Many other actions are restricted by design, and there are no entitlements to allow sandboxed apps to send AppleEvents to other apps, to use the Accessibility APIs for controlling other applications, and so forth. Add that to other restrictions already in place for the Mac App Store – such as not allowing privilege escalation by asking for an administrator password, system preference panels, etc. – and it’s understandable that developers are viewing the forthcoming sandbox requirement with trepidation and even anger.
On the other hand, for the user, sandboxing has its advantages. Losing data by program bugs or malicious code is restricted to the few places where read-write access is granted. Applications that “phone home” won’t be able to do so unless network access is allowed by an entitlement. If the entitlements are carefully chosen and restricted to the exact functionality of the app, everything should be well.
Unfortunately, the current entitlements are relatively few and more related to Apple’s initial ideas about what type of app should be on the Mac App Store – a game or relatively simple document-based application, perhaps. Now that Gatekeeper will be allowing “identified developers” to sign applications, Apple should also encourage these developers to use the sandbox. Well-known developer Daniel Jalkut says that the sandbox should be expanded:
Apple should embrace the utility of sandboxing by shifting their focus away from sandboxing only Mac App Store titles, to a strategy that would sandbox virtually every Mac app, inside the store or out…
To increase adoption, Apple should expand the current list of entitlements until it covers every reasonable behavior that users expect from Mac apps…
Finally, Apple should take a cue from its own Gatekeeper approach. By incorporating sandbox information about apps into the forthcoming app security preference pane, they will empower users to understand application intentions.
I agree fully with Daniel but would like to expand his proposal even more. We need more fine-grained entitlements that also encompass things that are currently done by older methods. For instance, to interact with other apps over the Accessibility APIs, application’s binaries need to be blessed with the old Unix setgid bit – or the user has to be oriented to allow all and any applications to do this. This would be easily solved by a specific entitlement. No doubt some entitlements might be restricted to administrator-level users. All in all, expanded entitlements will be in the general interest.
All that’s missing is an easy way of communicating to the user what entitlements the sandboxed application has set into its signature. Rather than do this in the security preference pane, I’d like to renew the idea I mentioned in my previous post: an information panel that’s shown on the first run for a signed application (and easily found by the user for re-checking thereafter). Besides showing information about the code signature and the authoring developer, this panel should also show a concise explanation of the entitlements requested by the application; with that information, the user can fully decide whether running that app will be worthwhile. Hm, why does this game want access to my Address Book, to the Internet, and read/write access to my entire hard drive? Looks suspicious…
This would take care of applications signed by identified developers. Unsigned applications that run without a sandbox should rightly be viewed with some suspicion. I don’t see many arguments in favor of anonymously-authored applications, but in any case, with the upcoming model, the user always has the option to make exceptions.
There remains great controversy about what was, until a few days ago, the main use for the sandbox: in Mac App Store applications. There was no incentive for non-MAS apps to be sandboxed, and Apple seemed to be unyielding in expanding the available entitlements – the gist on the developer forums seemed to be “either fit in the sandbox as it is or don’t sell over the MAS”. There are temporary exceptions and some (very few) developers got personal workarounds, but it all feels very constraining. In my opinion, it’s extremely worthwhile for developers to file feature requests for the sandbox outside the MAS. After all, it’s in Apple’s own interest to see wider sandbox adoption, and the hope is that some of those new entitlements will – after some time – flow back to benefit MAS apps.
Who knows, perhaps Apple will, in time, allow identified developers to sell iOS apps outside the App Store? It all depends on how successful that model is on the Mac. After all, confluence should go both ways!
Update: I just found Uli Kusterer‘s article about the sandbox which makes several of the same points, including one I’d forgotten to mention above: entitlements could easily refer to other applications just by mentioning their bundle ID (and perhaps, distinguishing between sending AppleEvents to that app, accessing their preferences or sandboxed files, and so forth).
” service;
