Fix The Sandbox
February 17th, 2012Apple’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.
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.
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!)
February 17th, 2012 at 5:12 pm
That’s a great post Daniel. It brings up some interesting points but I don’t think Apple are staying that sandboxing is dead. They haven’t stumbled. Right now you can download an app from the store safe it’s been vetted or you can download an app from the web and it could have come from anywhere and do anything to your system (a harsh outlook but true).
Now it would make the most sense to vet everything via the app store before people can run an app but for alot of developers who are stuck in the past this just isn’t going to work and there’s always the software that shouldn’t be distributed publicly but you still might want to validate it’s integrity somehow. This is where I see Gatekeeper certificates coming in. If nothing else for the software you get on CDs when you buy a new piece of hardware… You want to know the source is good but Apple still have the power to pull the security rug from under their feet if they misbehave. A full blown sandbox outside the app store would surely just be really annoying. Don’t forget either that we’ve only had this infrastructure to vet software via the internet for the past year and before that we just went on instinct and word of mouth to trust an app. So in my mind gatekeeper is a simple but very smooth move.
http://www.apple.com/macosx/mountain-lion/security.html
February 17th, 2012 at 5:13 pm
Great article! How does your sandbox vision fit with SELinux? I have to admit I’ve always disabled that tech as step 1 on redhat-ish boxen.
February 18th, 2012 at 3:21 pm
Interesting idea, but impractical.
Expecting customers to take charge of entitlements is wisjung your life away. The vast majority of customers will just click ok on any dialog box that pops up or look for some wy to disable it (like when Vista launched).
February 20th, 2012 at 1:37 pm
“but for alot of developers who are stuck in the past”
I am by no means and expert but I do follow some of the discussion on the Apple developer website regarding Sandboxes and I don’t think the above statement is accurate. It is my impression that some types of applications to implement in a Sandbox. For example I don’t think it’s possible (at least under the current sandbox environment) to support application ‘plug-ins.’ There also seems to be issues with applications that work with files that the applications itself did not create.
February 20th, 2012 at 5:45 pm
Really dumb question: does Apple maintain an open bug board for developers and users alike?
February 20th, 2012 at 10:02 pm
There is an Apple bug tracker, but you can only read the bugs you submit if you don’t work for Apple.
February 22nd, 2012 at 1:19 am
“Really dumb question: does Apple maintain an open bug board for developers and users alike?”
bugreport.apple.com
February 22nd, 2012 at 11:23 am
Here’s how to fix the sandbox:
1. A fresh install of OS X should include ONLY the absolutely essential software needed for the computer to run. No Safari, no Mail, no Calendar, no Contacts. Not even Chess. Pretty much the only installed apps would be System Preferences and the stuff in the Utilities folder.
2. Those apps that formerly shipped with OS X, along with all of Apple’s other apps, should be distributed through the App Store and have to play by all of the same rules as third-party applications. The only exceptions I would make would be for things like Xcode or OS X Server.
Bottom line: if Apple had to play by all of the same rules for their apps as third-party developers, you bet all of the necessary entitlements would be there. To be fair, I would apply this same set of rules to iOS as well.
In conclusion, to keep things as simple as possible for new users, after installing OS X (or upon first boot for a new system), the user should be prompted to install those apps that he/she wants. Apple could even have a “default” selection that includes all of the apps that formerly were installed by default.
February 22nd, 2012 at 2:51 pm
Sorry, I have to disagree – *vehemently* – that pushing off the issue of approving app behavior onto users, via entitlements, is a good idea. In almost any respect. This is what Android does, and it’s a disaster there.
The essential problem is that you’re asking users to think and act like programmers. Which may be fine for a small percentage of power users, but doesn’t work at all for average users.
First, entitlements would have to be described in clear, simple language that is understandable to ordinary users. This is one area where Android fails, badly; I used to do native-code Toolbox programming, I still do database development, and even for me the descriptions of some of the Android entitlements are opaque, to say the least. How many hundreds of entitlements would be required to cover the full range of behavior of MacOS applications, and what are the chances of doing a clear, coherent non-programmer description of each and every one of them?
Second, it puts too great a burden on non-programmers to connect the dots – and this will only get worse as the number and granularity of entitlements increases. To use the Path situation as an example: Path would presumably list an entitlement to access the Address Book – which, hey, it’s a social networking app, that sounds reasonable. And it would list network access as an entitlement – which again, it’s a networking app, what would you expect? But then the onus is put on the user to put these two together and say ‘Wait a minute, that means it could upload my address book to some network site!’ Except of course that it doesn’t automatically mean that, because an app doesn’t *have* to connect the entitlements that way.
Certainly I agree that the number of entitlements needs to increase for the Sandbox to be viable. But unless I’m misreading what you’re saying with “Apple should take a cue from its own Gatekeeper approach”, I think it’s a very bad idea for Apple to loosen up its App Store restrictions by pawning the approval issue onto users.
February 22nd, 2012 at 3:59 pm
Greaat!
February 23rd, 2012 at 6:36 am
Great article! I do completely agree that Apple’s sandbox is too restrictive, and too silent. It needs to add the ability to handle “runtime entitlements” whereby if an application wishes to do something that it isn’t currently allowed to do, then the user is informed clearly, and given the option to allow, deny, or always allow that behaviour.
This can also be complemented by expanding the sandboxing entitlements, but provide the user with a dialogue the first time they run an app, unless the entitlements are all non-threatening ones, so they can see at a glance that their new app needs read access to X and Y, as well as read/write access to Z.
While I can appreciate that Apple doesn’t want to bombard users with security dialogues, trying to hide all the workings of the security systems is not good either; I’m very much of the opinion that giving users a sane amount of information about what’s going on, is enough to allow them to protect themselves.
Anyway, I want to finish by pointing out that it is possible to apply sandboxing to your apps and then enable exceptions for things that sandboxing is currently too restrictive to prevent. If you’re doing this though then do make sure to let apple know via bugreport.apple.com so they know why! So long as the app store review process is looking at entitlements/exceptions to make sure you’re not picking weird ones that make no sense, then I think this should be okay.
But yeah, it’s all way to simplistic at the moment, and simple isn’t always better.
February 23rd, 2012 at 10:00 am
This would be a lot more convincing if you were explicit about how it will break MarsEdit, for example. I looked at the list that is currently supported and I didn’t notice any crucial missing entitlements, but I don’t know what your app does internally.
February 23rd, 2012 at 10:16 am
Hi Ross – I agree it would be a nice to go into more details about how sandboxing threatens existing apps. I will consider blogging separately about that.
I would like to point out that I never said this is about MarsEdit in particular. Don’t assume that just because I’m complaining, it’s entirely self-serving. In fact, the primary point of my complaint and criticism of sandboxing has more to do with the widespread impact it will have on a large variety of applications. MarsEdit, as it happens, is relatively easy to adapt to sandboxing compared to some other types of applications.
February 23rd, 2012 at 1:04 pm
Gatekeeper cannot stand in for Sandboxing. The two don’t solve the same issue. The purpose of Gatekeeper is to reduce the spread of known malware, where Sandboxing is a way to mitigate potential (inevitable) bugs that allow an otherwise non-malware app to be compromised.
February 26th, 2012 at 4:24 am
how does this compare to MS’ sandboxing rules for Windows 8 & Metro Apps? Anyone know?