Lion is most definitely not an internals-focused release, but it's also big enough that it has its share of important changes to the core OS accompanying its more obvioususer-visible changes. If this is your first time reading an Ars Technica review of Mac OS X and you've made it this far, be warned: this section will be even more esoteric than the ones you've already read. If you just want to see more screenshots of new or changed applications, feel free to skip ahead to the next section. We nerds won't think any less of you.

Security

Apple's approach to security has always been a bit unorthodox. Microsoft has spent the last several years making security a top priority for Windows, and has done so in a very public way. Today, Windows 7 is considered vastly more secure than its widely exploited ancestor, Windows XP. And despite the fact that Microsoft now distributes its own virus/malware protection software, a burgeoning market still exists for third-party antivirus software.

This approach is typical of Apple: don't say anything until you have something meaningful to say. But it can be maddening to security experts and journalists alike. As for end-users, well, until there is a security problem that affects more than a tiny minority of Mac users, it's hard to find an example of how Apple's policies and practices have failed to protect Mac users at least as well as Microsoft protects Windows users.

Sandboxing

Just because Apple is quiet, that doesn't mean it hasn't been taking real steps to improve security on the Mac. In Leopard, Apple added a basic form of sandboxing to the kernel. Many of the daemon processes that make Mac OS X work are running within sandboxes in Snow Leopard. Again, this was done with little fanfare.

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.

In Lion, the sandbox security model has been greatly enhanced, and Apple is finally promoting it for use by third-party applications. A sandboxed application must now include a list of "entitlements" describing exactly what resources it needs in order to do its job. Lion supports about 30 different entitlements which range from basic things like the ability to create a network connection or to listen for incoming network connections (two separate entitlements) to sophisticated tasks like capturing video or still images from a built-in camera.

It might seem like any nontrivial document-based Mac application will, at the very least, need to declare an entitlement that will allow it to both read from and write to any directory owned by the current user. After all, how else would the user open and save documents? And if that's the case, wouldn't that entirely defeat the purpose of sandboxing?

Apple has chosen to solve this problem by providing heightened permissions to a particular class of actions: those explicitly initiated by the user. Lion includes a trusted daemon process called Powerbox (pboxd) whose job is to present and control open/save dialog boxes on behalf of sandboxed applications. After the user selects a file or directory into which a file should be saved, Powerbox pokes a hole in the application sandbox that allows it to perform the specific action.

A similar mechanism is used to allow access to recently opened files in the "Open Recent" menu, to restore previously open documents when an application is relaunched, to handle drag and drop, and so on. The goal is to prevent applications from having to request entitlements that allow it to read and write arbitrary files. Oh, and in case it doesn't go without saying, all sandboxed applications must be signed.

Here are a few examples of sandboxed processes in Lion, shown in the Activity Monitor application with the new "Sandbox" column visible:

Sandboxed processes in Lion

Earlier, the Mac App Store was suggested as a way Apple might expedite the adoption of new Lion technologies. In the case of sandboxing, that has already happened. Apple has decreed that all applications submitted to the Mac App Store must be sandboxed, starting in November.

Privilege separation

One limitation of sandboxing is that entitlements apply to an entire process. A sandboxed application must therefore possess the superset of all entitlements required for each feature it provides. As we've seen, the use of the Powerbox daemon process prevents applications from requiring arbitrary access to the file system by delegating those entitlements to another, external process. This is a specific case of the general principle called privilege separation.

The idea is to break up a complex application into individual processes, each of which requires only the few entitlements necessary to perform a specific subset of the application's total capabilities. For example, consider an application that needs to play video. Decoding video is a complex and performance-sensitive process which has historicallyled to inadequate protection against buffer overflows and other security problems. An application that needs to display video will likely do so using libraries provided by the system, which means that there's not much a third-party developer can do to patch vulnerabilities where they occur.

What a developer can do instead is isolate the video decoding task in its own process with severely reduced privileges. A process that's decoding video probably doesn't need any access to the file system, the network, the built-in camera and microphone, and so on. It just needs to accept a stream of bytes from its parent process (which, in turn, probably used Powerbox to gain the ability to read those bytes from disk in the first place) and return a stream of decoded bytes. Beyond this simple connection to its parent, the decoder can be completely walled off from the rest of the system. Now, if an exploit is found in a video codec, a malicious hacker will find himself in control of a process with so few privileges that there is little harm it can do to the system or the user's data.

Though this was just an example, the QuickTime Player application in Lion does, in fact, delegate video decoding to an external, sandboxed, extremely low-privileged process called VTDecoderXPCService.

QuickTime Player with its accompanying sandboxed video decoder process

Another example from Lion is the Preview application, which completely isolates the PDF parsing code (another historicsource of exploits) from all access to the file system.

Putting aside the security advantages of this approach for a moment, managing and communicating with external processes is kind of a pain for developers. It's certainly less convenient than the traditional approach, with all code within a single executable and no functionality more than a function call away.

Once again in Lion, Apple has provided a new set of APIs to encourage the adoption of what it considers to be a best practice. The XPC Services framework is used to manage and communicate with these external processes. XPC Service executables are contained within an application's bundle. There is no installation process, and they are never copied or moved. They must also be part of the application's cryptographic signature in order to prevent tampering.

The XPC Service framework will launch an appropriate external process on demand, track its activity, and decide when to terminate the process after its job is done. Communication is bidirectional and asynchronous, with FIFO message delivery, and the default XPC process environment is extremely restrictive. It does not inherit the parent process's sandbox entitlements, Keychain credentials, or any other privileges.

The reward for breaking up an application into a collection of least-privileged pieces is not just increased security. It also means that a crash in one of these external processes will not take down the entire application.

We've seen this kind of privilege separation used to great effect in recent years by Web browsers on several different platforms, including Safari on Mac OS X. Lion aims to extend these advantages to all applications. It also makes Safari's privilege separation even more granular.

Safari in Lion is based on WebKit2, the latest and greatest iteration of the browser engine that powers Safari, Chrome, and several other desktop and mobile browsers. Safari in Snow Leopard already separated browser plug-ins such as Flash into their own processes. (Adobe should not consider this an insult; Apple does the same with its own QuickTime browser plug-in.) As if to further that point, WebKit2 separates the entire webpage rendering task into an external process. The number of excuses for the Safari application to crash is rapidly decreasing.

As the WebKit2 website notes, Google's Chrome browser uses a similar approach to isolate WebKit (version 1) from the rest of the application. WebKit2 builds the separation directly into the framework itself, allowing all WebKit2 clients to take advantage of it without requiring the custom code that Google had to write for Chrome. (Check out the process architecture diagrams at the WebKit2 site for more detailed comparisons with pre-Lion WebKit on Mac OS X and Chrome's use of WebKit.)

John Siracusa
John Siracusa has a B.S. in Computer Engineering from Boston University. He has been a Mac user since 1984, a Unix geek since 1993, and is a professional web developer and freelance technology writer. Emailsiracusa@arstechnica.com//Twitter@siracusa