OS X Lion: Understanding the puzzle of sandboxing

With OS X Lion, Apple has introduced many new features for users, but also for developers. One of them is the sandboxing applications, mandatory term for distributed applications through the Mac App Store. What is sandboxing? What changes does it for users? And especially that he changes for developers?

A sandbox with walls twelve feet high

It is traditionally possible for an application to access all data and software and hardware functions available. This logic, which makes the operating system on the front of the stage, has allowed the development of many system utilities, drivers, and most advanced applications. In this case, an application is free to come and go on his playground, and to do what she wants.

The sandboxing is a practice inherited from IOS, which focuses on the use of applications, the operating system becoming - to summarize very roughly - a set of services. For the purposes placed in sandbox, nothing exists other than what the system allows him to see (some files explicitly required, placed in a folder "virtual" in the sandbox) and use (a reduced set of APIs), all being controlled by a system of signatures provided by Apple. The system can, if needed, remove the application data. In this case, the playing field consists of multiple sandboxes with walls twelve feet high, each containing an application can not escape, feeding the system with the pipette just enough to be practical - or fun to trample on his sand castle if necessary.

This logic has been the success of IOS, as safe and convenient double argument. The security argument can be easily understood: as a sandbox, the application can compromise the security of the system or other applications running arbitrary code or by directly accessing hardware features. The system shall provide only what it needs, and the application can not departing from its scope. The practical argument is that the optimization and consistency of the software environment: all applications have access to the same set of services provided by Apple, the same methods.

The security issue is found on OS X: in theory, greatly limit the sandboxing security risks. Apple shows the way with three system applications using the sandbox: Safari, Mail, and Preview. Three applications are often sources of problems through various loopholes, especially in the management of PDF and TIFF files, faults that makes sandboxing inoperative by confining them to the limited space of the application, isolated from the system. The sandboxing is controlled by a system of signatures provided by Apple, the system can at any time verify the validity of an app: a malware has changed an application, and his signature is no longer valid? OS X will refuse to run it.

Because this system enhances the relative safety of OS X, Apple has decided to make it mandatory for any distributed application in the Mac App Store by March 2012. Developers will have to choose between flexibility and the presence in the Mac App Store.

You should know because keeping: with all technologies and APIs made available by Apple, and these permissions, it is possible to build applications very advanced and very useful. Of course, Apple will be asked to fully justify the permissions required, but may occasionally grant access to certain resources (such as Apple Events), at least temporarily. But all of a piece of commercial applications is excluded because:

since it is impossible to go further than the system in the management of Bluetooth, FireWire, or Thunderbolt, many utilities will not be in the Mac App Store; it is equally impossible to access a service started by an application or to interact with the functions of an application, iTunes controllers, communication systems between applications or system overlays (such as TextExpander) can not not be in the Apple store;

As it is impossible to access the entire file system, FTP clients and backup software will have to be out of the Mac App Store, considerably complicate their operation, to seek the agreement of the user at each stage; Finally, since all that could be likened to the execution of arbitrary code is no longer acceptable, many applications will not be accessible through AppleScript, Plug-ins will be challenged, and extending all utilities their functions through small files extensions will have to find another solution.

Safety against flexibility, the choice is clear, and there are problems. Several developers have already voiced their doubts as to their remains in the Mac App Store. But does this pose really a problem for developers of utilities used by a minority or knowledgeable with big studios do not want to concede 30% to Apple? Nothing is less certain, and typical applications of the Mac App Store are the ones that should have less difficulty in adopting the sandboxing. This echoes the classic problem of technological transitions (Carbon> Cocoa, PPC> Intel, etc..), Which require some relearning reflexes and discover new ways to do certain things.

We can nevertheless criticized Apple certain lightness in its communication on the subject: While it supports the developers, but the simple fact that it has itself extended the deadline for adopting the sandboxing of October 2011 to March 2012 is the red flag. The Cupertino company itself is not ready. The Safari bug with fonts was a problem with the sandbox (read: Leo blocks the police managers with Webkit), a system complicated enough to put in place for Apple to give extra time for polish.

The limitations of sandboxing

Sandboxing, by its nature, requires great attention from Apple: the slightest flaw could be exploited and cause considerable damage. Apple would then have the choice to update OS X, as soon as possible preferably. And as pointed Wil Shipley, developer of Delicious Library, the "perfect code" does not exist, especially on an OS that "as many statements that have the human brain," in the words of Bertrand Serlet. Apple says it will check carefully all applications and permissions requested, but validation App Store has already shown its weaknesses, is another problem.

A malicious application could therefore ask permission to move some the cracks unnoticed, and then use a hole, or be faced with a door wide open, even without permission to do certain things. The teams have good validation check App Store applications, they are in no way perfect: Charlie Miller has until recently been able to submit an application able to download the IOS remote code to run locally. This application is then two things: use all the permissions to retrieve as much data (photos, contacts, etc..), And divert the functions of the OS to its own advantage (read: A flaw that is completely failing system validation of the App Store). Such malice is just as possible on OS X Lion: just hold on to all the little rough around the walls built by Apple applications.

In short, if the sandboxing will mechanically increase security on OS X, simply by its forced adoption by developers, it is by no means a panacea. No solution, however, can claim miraculous, the sanboxing can be bypassed, the certificates can be diverted (read: OS X Lion and the issue of certificates TLS / SSL), code verification is never enough. All these solutions can however improve overall security, the price of a few adjustments for developers - and that's what counts in the eyes of Apple.

In addition, the strategy is clear: OS X gets closer and closer to iOS. In addition to standardize development and improve safety, sandboxing, also facilitates the backup and uninstalling apps. A crucial point of IOS, which is in the process of becoming on OS X with the Launchpad, the lapsed the Finder file management through the integration of apps and icloud. The word "application", born on the Mac as opposed to "program" to refer to software and specialized single task, is also the key to understanding the evolution of OS X via IOS. The system is a huge machinery less visible and more transparent, which is not a platform that can hack, but an engine for multiple applications. A move that now seems inevitable.