Apple has given developers yet another few months to implement application sandboxing for OS X apps, a security feature brought over from iOS: the deadline is now June 1, 2012. While the intent of sandboxing is to prevent hacked apps from taking over a user's system, however, the sandbox design inherently limits functionality that users and developers have come to expect on the desktop. Apple's changes and delays to sandboxing requirements have also created a situation where the sandboxing goalpost keeps moving while developers continue to push Apple to improve its design.
What does Apple mean by sandboxing?
An application can run in its own "sandbox," a protected space separated from other apps and the operating system. While inside the sandbox, apps can't do bad things like delete a user's entire directory, or open network connections and phone home to a botnet server.
As John Siracusa explained in his review of Lion last year:
Running an application inside a sandbox is meant to minimize the damage that could be caused if that application is compromised by a piece of malware. A sandboxed application voluntarily surrenders the ability to do many things that a normal process run by the same user could do. For example, a normal application run by a user has the ability to delete every single file owned by that user. Obviously, a well-behaved application will not do this. But if an application becomes compromised, it may be coerced into doing something destructive.
Apps running in a sandbox have a harder time getting into other apps' sandboxes, but that can also limit the functionality of an app to an extent that it could no longer be useful. For instance, according to Bare Bones' Rich Siegel, the BBEdit text editor would not be able to do a multifile search and replace, show live folder views of complete programming projects, or integrate with version control systems if sandboxed.
"You quickly start running into problems if this sandboxing stuff gets carried to a rigorous and/or logical conclusion," Siegel told Ars last November. "I'm sure there are lots of businesses who've built automation workflows, which fanatical sandboxing would completely break."
A moving goalpost
Originally, Apple set a November deadline for developers to use OS X Lion's app sandboxing capabilities lest their apps be barred from the Mac App Store. But as developers struggled to work within the limits of Apple's sandboxing implementation, Apple extended the deadline to March 1, 2012. And now in an e-mail to developers on Tuesday afternoon, Apple again extended the deadline to June 1.
In particular, Apple noted that the recent release of Mac OS X 10.7.3 introduced additional "entitlements," special privileges that apps can claim from the operating system to do things like access files, send and receive Apple Events, use hardware resources like a FireWire port or FaceTime camera, or connect to the Internet.
"We have extended the deadline for sandboxing your apps on the Mac App Store from March 1st to June 1st to provide you with enough time to take advantage of new sandboxing entitlements available in OS X 10.7.3 and new APIs in Xcode 4.3," Apple wrote.
Furthermore, Apple is encouraging developers to file bugs against sandboxing entitlements that they feel are missing. Developers can also request a temporary entitlement from Apple, evaluated on a case by case basis, to enable functionality not covered by the existing entitlements.
Unfortunately, the changes now present several new conundrums for developers. Many apps have to be significantly re-architected to work within sandboxing limits. That's a lot of work for a relatively low security benefit, argued Red Sweater's Daniel Jalkut.
For instance, apps targeting OS X 10.7.3 for its expanded sandbox entitlements will still run on Snow Leopard (10.6) or even earlier versions of Lion. Under Snow Leopard, apps simply run without sandboxing altogether. However, under 10.7.0 to 10.7.2, certain functionality that requires entitlements introduced in 10.7.3 simply won't work—the system won't be able to grant the necessary entitlements.
Developers are considering how to handle those edge cases. Should the app try to work around the limits, or should an app just alert the user that it won't work unless Lion is updated? Or should Apple develop a better way to handle the entitlements regardless of OS version?
"Apple's delay acknowledges the challenges of sandboxing both for developers and for Apple," Jalkut told Ars, suggesting Apple should in fact push the sandboxing requirement to the release of OS X 10.8 (Mountain Lion) this summer. "I think everything sandboxing related up to now should be considered a sort of test run," he said, and Apple should consider an alternative way of enabling sandboxing on the desktop.
"It's a good thing that Apple is listening to developers with respect to sandboxing. I see Apple's approach to this now as an iterative process of chipping away at remaining shortcomings in sandboxing," Jalkut said. But it's clear that sandboxing isn't yet a workable solution for improving security on the desktop as it has been for Apple's mobile platform.
Gatekeeper, a new security feature coming to Mountain Lion, may offer a better alternative to sandboxing, at least in the short term. Gatekeeper works by allowing users to control whether apps obtained from the Mac App Store, from registered developers, or from anyone can be run on a user's system.
"Gatekeeper provides a huge security benefit for very little developer cost and no changes to application design," Jalkut noted. "Sandboxing, by comparison, is a huge amount of work for both Apple and developers, and in the context of Gatekeeper may provide little additional protection to users."
reader comments
37