The Sandbox’s Big Red Button
May 12th, 2012If you’ve been following the debate surrounding Apple’s Application Sandbox, you know that many developers are concerned about the implications for existing apps of adopting the sandbox.
Apple has been threatening for almost a year that apps for sale in the Mac App Store will need to embrace the Application Sandbox, or else further updates to the apps will not be accepted. The deadline for adopting the sandbox has slipped several times, but it currently rests at June 1, 2012. That’s only a few weeks away, and comes just ahead of Apple’s annual developer conference.
I’ve written a few rants about the Application Sandbox, culminating in my February 2012 piece imploring Apple to “Fix the Sandbox.” Slowly but surely, they are improving the technology that drives the sandboxing features of Mac OS X, but by June 1, it appears that many classes of application will still be “unsandboxable” under the current permissions model supplied by Apple.
The shortage of permissions, or “entitlements” in sandbox lingo, has always been at the root of my concerns. Especially because of the political move requiring existing Mac App Store apps to adopt the sandbox, it is easy to imagine a features bloodbath come June, or whenever the requirement goes into place. When Apple announced the postponement to June 1, they also took care to make assurances that bug-fix updates would still be allowed for non-sandboxed apps, which is a nice break, but will still leave many apps to die on the vine in lieu of suitable sandboxing entitlements for the features various apps provide.
Apple publicly documents the list of entitlements available to Mac software developers. One of my major concerns has always been that because the list of entitlements doesn’t cover all the nuanced, legitimate tasks that an app might want to perform on a user’s behalf, that Application Sandbox ran the risk of permanently forbidding certain types of application behavior from being conducted in the sandbox.
The high-level list of Application Sandbox permissions is intentionally coarser-grained than the lower-level “sandbox facility” which ultimately imposes the restrictions. Some developers criticize Apple for failing to embrace the sanbdbox with their own apps, while expecting developers to embrace it for the Mac App Store. On Mac OS X 10.7.4, the two notably sandboxed apps from Apple remain Preview and TextEdit, two apps that would be relatively simple to sandbox compared to a large number of complex, 3rd party products.
But Apple has applied a good deal of sandboxing to their code. For example, take a look at /usr/share/sandbox/ and /System/Library/Sandbox/Profiles/ for examples a variety of “.sb” files that specify the sandbox restrictions of a variety of system services and tools. These files are expressed in SBPL, or the Sandbox Policy Language, which is a scheme-based language used to express the fine-grained permission the sandbox facility is capable of controlling. See my “Sandbox Corners” for a bit more about the lower-level sandbox facility and SBPL files.
Today I decided to take a closer look at one SBPL file of particular interest: /System/Library/Sandbox/Profiles/application.sb. This is the SBPL file that, so far as I can tell, translates the high-level “entitlements” of the Application Sandbox into corresponding lower-level policy expressions for the sandbox facility. For example:
(if (entitlement "com.apple.security.network.client")
(allow network-outbound (remote ip)))
You can get a taste for how the high level “I’m a network client” translates specifically to “allow out bound ip traffic” at the sandbox facility level. Other high-level rules express much more complex logic. For example, the “I want to use the printer” entitlement translates to a variety of low-level permissions to communicate with printer-system daemons, and read from printer configuration files on the system.
But by far the most interesting entitlement of all is one that I found at the bottom of application.sb. It’s not documented on Apple’s site, and from what I can tell this blog post will become the first Google match on the term. The entitlement is “com.apple.security.temporary-exception.sbpl”, and the comment above it reads simply: “Big Red Button”.
;; Big Red Button
(sandbox-array-entitlement
"com.apple.security.temporary-exception.sbpl"
(lambda (string)
(let* ((port (open-input-string string))
(sbpl (read port)))
(eval sbpl))))
This temporary entitlement enables a high-level Application Sandbox-restricted application to supply, along with whatever other high-level entitlements it requests, an entitlement that brings with it as a parameter a literal SBPL program, that will be evaluated and thus applied by the lower-level sandboxing facility.
In short: the Big Red Button gives Apple an out.
Whatever mistakes they make in the devising of high-level entitlements can be theoretically undone after-the-fact by supplying developers with special Big Red Button entitlements that pass along specific permissions to the lower-level sandbox, liberating the application to do whatever important task it needs to do.
Of course, the fact that this facility exists does not say anything about whether Apple will indulge its use. And just because you, as a developer, could use this entitlement key to empower your sandboxed app to do practically anything, it doesn’t mean that Apple’s App Store reviewers would look kindly upon it. In fact, I’m almost positive that at this point, any developer who submits a sandboxed app with this entitlement will have to have already conversed extensively with Apple about the need for such a transgression.
But the entitlement is there, and that makes me breathe a little easier. The Application Sandbox is, so far as I can tell, technically capable of granting whatever permission any app could reasonably need. The only obstacle, and it’s a big one at that, is the political challenge of App Store approval.
Update: John Brayton made an interesting point in the comments, that regardless of MAS policy, the Big Red Button might be useful to non-MAS developers who wish to adopt the Application Sandbox , but can’t manage to squeeze all their functionality into the confines of its entitlements. I originally thought this made good sense, but then realized how risky a move this would be in practice. Because the entitlement in question here has not been documented by Apple, and is furthermore only listed in an implementation file for the system itself, the behavior of this entitlement can’t be relied upon.
Indeed, above I suggested that the entitlement would grant developers the power to enable virtually any capability in their sandboxed apps, but we have no idea how Apple has actually implemented support for the entitlement inside Apple. They could very well have a special case inside the SBPL language evaluator itself that looks for and rejects scripts that it doesn’t recognize as its own.
The application.sb file even has a strong disclaimer to this effect:
WARNING: The sandbox rules in this file currently constitute Apple System Private Interface and are subject to change at any time and without notice. The contents of this file are also auto-generated and not user editable; it may be overwritten at any time.
In other words: you can’t count on the details of this file remaining stable from release to release. It would be foolish to base the behavior of any shipping app on entitlements listed there, but not documented by Apple. I think the Big Red Button is a very interesting find, and I’m very curious about it. But that’s how it should be considered: as a curiosity.
May 12th, 2012 at 4:55 pm
“the two notably sandboxed apps from Apple remain Preview and TextEdit, two apps that would be relatively simple to sandbox”
Do you mean *non*-sandboxed apps in this sentence?
May 12th, 2012 at 4:59 pm
This could provide an interesting way to “sandbox” non-MAS builds but still allow them to use Sparkle. Both the MAS and non-MAS editions of an app would (I assume) keep their preference files and Application Support directories in the sandbox container.
May 12th, 2012 at 5:01 pm
I thought at some point they said you’d be able to request additional access, as long as it was well-justified. This seems like it is how they intend to support that.
May 12th, 2012 at 5:17 pm
Guan Yang – no, the apps are the two that ARE sandboxed by Apple.
May 12th, 2012 at 5:17 pm
Poking a hole as an out is one thing, but that thing is also explicitly labelled a “temporary exception”. What about apps, like your own FastScripts, that work in a way that’s fundamentally incompatible (Apple events to other, pre-unknown, apps) and that won’t change any time soon?
What if you have to continually explain your predicament with every submitted update? What if they’ll cut you off after a while? What if they introduce some new replacement technology and you will be unable to retrofit FastScripts to work with it, or will force you to leave the older technology behind?
Maybe having the exception there is admirable as it is the end result of careful planning, expecting that things can go wrong and wanting the world to go on despite that. But there are more obstacles remaining than just getting it approved.
May 12th, 2012 at 5:18 pm
But they still haven’t provided a way to have the “digital hub” actually work for non-apple apps – i.e., let the user use their iPhoto Library or iTunes Library in non-apple apps. And filing a bug about this hasn’t gotten any “big red button” magic scripts or even a suggestion that this will be provided. Still SOL if you want to let the user access the photos the have in iPhoto from any other application (like apple does with iMovie, Pages, etc), for example. This will sort of work if you assume the images/music files are copied to the library and assume the library is located in Pictures, but those are both false assumptions in *many* real-world user scenarios.
Product is still killed due to sandboxing. :-(
May 12th, 2012 at 5:33 pm
Jesper – the idea with the temporary exceptions is that eventually the legitimate activities will have sanctioned, non-temporary entitlements that adequately cover the behavior. I agree with you that it’s a tall order for an app like FastScripts, because not only does it AppleEvent arbitrary apps, but it gets into the nitty gritty of how AppleScript handles the AppleEvents. But for example, they could provide a sanctioned “script runner” app that takes the permissions level up a notch so that a temporary entitlement for many apps becomes a sanctioned “script runner” entitlement.
May 12th, 2012 at 6:07 pm
Daniel: That’s just one possible outcome. It depends on how and why they use this. Either they use it while they build a matching entitlement or they use it to give you a reprieve.
Getting a script runner would indeed be a good way of solving the problem, but solving the problem isn’t the only outcome, and I think that bears repeating. Everything related to the process of determining what to additionally permit and officially sanction in the future is at least as interesting and relevant as the app review process from which it has to be separate (although complementary).
Insofar the existence of a red button means that they are more willing to accommodate developer wishes, it’s a good sign. But if it’s the extent to which they are willing to do that, it’s not.