Mac App Store Sandbox

Named to Mac App Store’s Best of 2012 at v2.7, 2.10 adds support for Karelia's new integrated Sandvox Hosting service. Only Sandvox — winner of an Apple Design Award — features a user experience that lets you combine and spotlight your own drag-and-drop content while automatically creating a modern, feature-rich, standards-compliant.

Apple’s getting a lot of press this week about their forthcoming 10.8 “Mountain Lion” update to Mac OS X. One of its key features will be a security feature called “Gatekeeper” that will allow users to avoid launching apps from developers who are not registered with Apple. If you are not already familiar with Gatekeeper, read Steven Frank’s writeup to get up to speed. You should also check out Wil Shipley’s post from this past November, where he argued for something very much like Gatekeeper.

I am excited about Gatekeeper not only because it will improve security on the Mac but because of how it will achieve this goal. Apple, as the authority in the OS X environment, will convey information to Mac users about who developed a particular application, empowering them to protect themselves. Compare this to the status quo of the App Store, where security is completely out of users’ hands, and Apple uses its discretion to protect users from software it judges unfit for consumption.

Who vs. What

Simply establishing the identities of software developers is a major step for increasing security, because bad actors can either be immediately shut down, or at least prevented from further propagating on the platform. If “Hawt Dawg Industries” is discovered to be a malware developer, Apple can flip a switch and any user who trusts Apple’s opinion about such things can automatically prevent their Macs from trusting software from that vendor.

If somebody knocks on your door in the middle of the night, the first thing you’re liable to ask is “Who are you?” That’s Gatekeeper. Sometimes, the “who” is all the information you need. But if there’s any doubt, the next bit of information you’ll pry for is “What do you want?” That’s the sandbox. At least, it’s what the sandbox will be, after Apple fixes it.

The Broken Sandbox

At its best sandboxing is a means for app developers to faithfully state their intentions in a manner that can be evaluated by users, and also be reliably enforced by the operating system. So if your new “Fun on Facebook” app declares its intention is to connect to the web, you might judiciously allow it. If it says it needs to write files to the root of the filesystem, you’d be wise to search for another app.

Sandboxing on the Mac works by providing developers with a standardized list of “entitlements” which are clear descriptions of things it would like to do on your Mac. Examples include: access the internet, read files from your Pictures folder, print things on your printer.

The number one broken thing about sandboxing as it stands today, is the list of entitlements is simply too limited. Many apps on the App Store, including my own, will need to have their functionality considerably diminished, or in some cases made outright useless, in order to accommodate the available list of entitlements that sandboxing offers.

To stretch the stranger-at-your-door metaphor a little further, imagine the visitor is your trusted plumber, who’s come to fix a leaking pipe. In response to “What do you want?” he’s a bit tongue-tied. There’s no “entitlement” for fixing pipes, so he’s forced to say “I’m here for a chat.” When you reluctantly let him in the door he informs you that actually, due to recent legal changes, he’s no longer allowed to fix your pipes.

The impending state of the Mac App Store is very much like this. A great number of apps provide useful services to grateful customers, but as those services don’t fit the mould of Apple’s sandboxing entitlements, they will be effectively barred from the store within a few weeks. If you want to hire somebody to “fix the leaky pipe,” you’ll have to look outside the store, where apps are not sandboxed at all, and where Apple is in no position to improve users’ knowledge about the “what” of an app.

Saving Face

Gatekeeper is extremely simple, yet is likely to be extremely effective. Some exasperated developers who have been frustrated by the sandbox limitations are hopeful that all this attention on Gatekeeper might indicate a change of heart on Apple’s part. Will they see the error of their ways and ditch sandboxing in favor of Gatekeeper’s elegance?

One problem with this approach is that Apple would appear as though it had stumbled in its strategy. It spent the greater part of a year selling the idea of sandboxing and all of its merits, then two weeks before its grand debut, jumps ship for a completely different approach? Smooth move, Apple.

Sandbox Mac Os

But a more important problem is that abandoning sandboxing would mean the significant engineering investment, both by Apple and by developers who have refactored their apps to satisfy sandboxing requirements, would have been a waste. There is such great value in sandboxing technology, we just need to finish the job of mining it out.

What should Apple do about all this? Gatekeeper and the Mac App Sandbox are both technologies that stand to improve security on the Mac by labeling apps with useful information about their developers and their functionality. The extent to which security is improved is very much tied to how widely adopted these technologies are. If the vast majority of developers agree to sign their apps with Gatekeeper certificates, then the vast majority of users will leave the Gatekeeper “safe” mode enabled.

Embrace, Expand, and Empower

Apple should embrace the utility of sandboxing by shifting their focus away from sandboxing only Mac App Store titles, to a strategy that would sandbox virtually every Mac app, inside the store or out. Given the current limitations of sandboxing, a significant number of developers will not adopt the technology, so its usefulness to users and to the security of the platform will be diminished. Apple can turn that around so that sandboxing is a worthy counterpart to Gatekeeper, and a technology that any developer in his or her right mind would feel foolish not to incorporate.

To increase adoption, Apple should expand the current list of entitlements until it covers every reasonable behavior that users expect from Mac apps. A good test for this is any app that is currently available in the Mac App Store. Having been approved by Apple’s own reviewers, and purchased by Apple’s own customers, the merit of these apps should be considered implicit. If a Mac App Store app’s reasonable behavior cannot be achieved in the confines of the sandbox, it should be considered a sandboxing bug, and a new entitlement should be added.

Finally, Apple should take a cue from its own Gatekeeper approach. By incorporating sandbox information about apps into the forthcoming app security preference pane, they will empower users to understand application intentions. Along with the proposed options controlling the “who” of apps, users would be given reasonable defaults pertaining to the “what” of apps. For power users, these settings would be configurable on an entitlement-by-entitlement basis. The sheer transparency will be yet another motivation for developers to adopt sandbox, and for users to demand sandboxing from their developers.

Mac App Store Sandbox Requirement

Imagine a future where the majority of Mac apps are signed with Gatekeeper certificates, and an accurate list of entitlements. Users will be protected by smart default settings, and by the knowledge of who their apps come from, as well as what they intend to do. Developers will be protected from their own unintentionally destructive mistakes, and from impostors selling software purported to be authentic. And Apple? Apple will be remembered as the huge, clever computer company that solved the software security problem on two fronts, without pissing off developers or customers. Much.

(This piece was inspired by a lunchtime chat with my friend Paul Kafasis. Thanks, Paul!)

App Sandbox is an access control technology provided in macOS, enforced at the kernel level. It is designed to contain damage to the system and the user’s data if an app becomes compromised. Apps distributed through the Mac App Store must adopt App Sandbox. Apps signed and distributed outside of the Mac App Store with Developer ID can (and in most cases should) use App Sandbox as well.

At a Glance

Complex systems will always have vulnerabilities, and software complexity only increases over time. No matter how carefully you adopt secure coding practices and guard against bugs, attackers only need to get through your defenses once to succeed. While App Sandbox doesn’t prevent attacks against your app, it does minimize the harm a successful one can cause.

A non-sandboxed app has the full rights of the user who is running that app, and can access any resources that the user can access. If that app or any framework it is linked against contain security holes, an attacker can potentially exploit those holes to take control of that app, and in doing so, the attacker gains the ability to do anything that the user can do.

Designed to mitigate this problem, the App Sandbox strategy is twofold:

App Sandbox enables you to describe how your app interacts with the system. The system then grants your app the access it needs to get its job done, and no more.
App Sandbox allows the user to transparently grant your app additional access by way of Open and Save dialogs, drag and drop, and other familiar user interactions.

App Sandbox is not a silver bullet. Apps can still be compromised, and a compromised app can still do damage. But the scope of potential damage is severely limited when an app is restricted to the minimum set of privileges it needs to get its job done.

App Sandbox is Based on a Few Straightforward Principles

By limiting access to sensitive resources on a per-app basis, App Sandbox provides a last line of defense against the theft, corruption, or deletion of user data, or the hijacking of system hardware, if an attacker successfully exploits security holes in your app. For example, a sandboxed app must explicitly state its intent to use any of the following resources using entitlements:

Hardware (Camera, Microphone, USB, Printer)
Network Connections (Inbound or Outbound)
App Data (Calendar, Location, Contacts)
User Files (Downloads, Pictures, Music, Movies, User Selected Files)

Access to any resource not explicitly requested in the project definition is rejected by the system at run time. If you are writing a sketch app, for example, and you know your app will never need access to the microphone, you simply don’t ask for access, and the system knows to reject any attempt your (perhaps compromised) app makes to use it.

On the other hand, a sandboxed app has access to the specific resources you request, allows users to expand the sandbox by performing typical actions in the usual way (such as drag and drop), and can automatically perform many additional actions deemed safe, including:

Invoking Services from the Services menu
Reading most world readable system files
Opening files chosen by the user

The elements of App Sandbox are entitlements, container directories, user-determined permissions, privilege separation, and kernel enforcement. Working together, these prevent an app from accessing more of the system than is necessary to get its job done.

Relevant chapters:App Sandbox Quick Start, App Sandbox in Depth

Design Your Apps with App Sandbox in Mind

After you understand the basics, look at your app in light of this security technology. First, determine if your app is suitable for sandboxing. (Most apps are.) Then resolve any API incompatibilities and determine which entitlements you need. Finally, consider applying privilege separation to maximize the defensive value of App Sandbox.

Xcode Helps You Migrate an Existing App to App Sandbox

Some file system locations that your app uses are different when you adopt App Sandbox. In particular, you gain a container directory to be used for app support files, databases, caches, and other files apart from user documents. Xcode and macOS support migration of files from their legacy locations to your container.

Relevant chapter:Migrating an App to a Sandbox

Preflight Your App Before Distribution

After you have adopted App Sandbox in your app, as a last step each time you distribute it, double check that you are following best practices.

How to Use This Document

To get up and running with App Sandbox, perform the tutorial in App Sandbox Quick Start. Before sandboxing an app you intend to distribute, be sure you understand App Sandbox in Depth. When you’re ready to start sandboxing a new app, or to convert an existing app to adopt App Sandbox, read Designing for App Sandbox. If you’re providing a new, sandboxed version of your app to users already running a version that is not sandboxed, read Migrating an App to a Sandbox. Finally, before distributing your app, work through the App Sandbox Checklist to verify that you are following best practices for App Sandbox.

Prerequisites

Before you read this document, make sure you understand the overall macOS development process by reading Mac App Programming Guide.

Globelucky