After the Mac App Store appeared in January 2010, Apple first indicated that sandboxing would become mandatory for all apps sold in the store by November. At the point, the deadline was shifted again until the beginning of March, in part because of complaints from developers and in part because of issues with the sandboxing mechanism itself.
Apple's mobile iOS platform has used sandboxing from the beginning, preventing the spread of viruses, malware and other serious security issues that have plagued other mobile devices ranging from Symbian to Palm OS to Android.
Sandboxing for Security
Apple initially began adding security sandbox features in Mac OS X Leopard. A sandbox provides an app with operating system controls that limit what it can do. The main security purpose of a sandbox is to prevent an app from doing anything it has no need to actually do, so that were it ever to be take over by malware, it simply couldn't do anything bad (within the foreseeable).
Apple has included sandbox support in some of its own apps bundled in Mac OS X, including Safari Web Content (something that helps reduce the damage caused by the Adobe Flash plugin when it fails or is compromised).
Preview and TextEdit also operate within a sandbox, with Preview isolating its PDF rendering in a secondary sandbox to negate any exploits hiding within PDFs. QuickTime sandboxes its video decoders, spinning off the task to processes named VTDecoderXPCService.
When Mac OS X Lion appeared, the system's sandbox support had grown sophisticated enough to be used by many common third party apps. Apple first anticipated that all apps sold in the Mac App Store would be sandboxed, but then gave developers a reprieve through November to study certain cases where this might cause more problems than it solved. The deadlined was then moved to March 1, just weeks from now.
Permissions for apps, just like users
Sandboxing works hand in hand with app signatures, serving as an app-centric security model with similarities to the users-centric file system model. When a user signs into a computer, he has account restrictions that might prevent him from deleting certain system files, for example. However, there's no finer grained control that can allow him to listen for network activity using a trusted app while blocking that same ability in a test app that he knows has no business to be accessing the network.
Sandboxes do for apps what file permissions does to files: they only allow access to certain features that have been designated in advance. Sandbox permissions are called "entitlements" (but share little in common with Android permissions model). There are over two dozen entitlements for app sandboxes in Mac OS X Lion, which range from the ability to read local files, to listening for network connections, to accessing the FaceTime camera to take pictures.
Because there's no way for the operating system to decide on its own what an app "should" or "shouldn't" be doing, developers must create apps that outline what they are designed to do, applying for entitlements that allow them to only do those specific, limited tasks.
By hardcoding an app's abilities to fit within an enforced set of entitlements, apps become safer because a flaw in the app that attempts do to something it has not been given permission to do (such as writing over your personal documents) is simply prevented by the sandbox rules. The same protections also prevent an app that might be infected with a virus or other malware from causing damage it was never expressly given the potential to ever cause.
Apple's sandbox technology is based upon the idea of being easy to use, rather than throwing lots of complexity at the user to figure out. So, rather than asking the user to interpret complex security policies, Apple watches for user intent and complies with what the user is doing.
When a user attempts to open a file or drags a file into an app, Mac OS X assumes the user is signaling an intent it should allow. Apple has built a mechanism for Mac OS X called Powerbox that enables sandboxed apps to open or save files at the user's direction, rather than trusting every app itself with full control of the file system.
Sandboxing can also serve as a way to split up a process into a series of tasks, allowing a heavy lifting component to be tightly secured in a separate sandbox with no connection to outside files or network access, greatly reducing any opportunities for finding vulnerable ways to attack the task, spread to infiltrate the entire program, and then subsequently take over the whole system.
Introducing this new structure and perimeters of security take more work, but it results in software that can better withstand crashes or even intentional attacks by malicious hackers, without suffering damage or at the very least, greatly limiting what the attacker can access.
While Apple has sought to avoid excessive work by developers, it wants Mac software to rapidly adopt these security features, and will soon (by the beginning of March) add sandboxing to the other minimum requirements of developers who want to sell software through the Mac App Store.
Apple has yet to bring sandboxing to its own iLife and iWorks apps, having focused initially on sandboxing apps and processes that run plugins or access codecs, such as Safari, Quick Look, QuickTime and Preview. That should change rapidly next month once the company's self imposed sandboxing deadline kicks in.
Apple similarly rolled out incremental enhancements its own bundled apps and separately sold app suites to incorporate support for 64-bit, starting with apps that benefitted most from the architectural shift.