Apple is in the midst of a major transition with the Mac platform. As users flock to the Mac, it’s only natural that criminals will follow — that growing market share makes the Mac community a sufficiently lucrative target. But it’s clear Apple recognizes this risk. Taking lessons from the currently malware-free world of iOS, Apple has been enhancing the security of Mac OS X since the release of Mac OS X 10.5 Leopard, slowly at first, and more significantly of late.
Apple’s strategy relies on five technical pillars: enhancing the foundational security of Mac OS X; hardening Safari (Web browsers being the most common avenue of attack today); encouraging apps to use sandboxing techniques to limit attack vectors; keeping the Mac App Store as free of malicious applications as possible; and, with 10.8 Mountain Lion, using Gatekeeper to reduce the ability of attackers to trick users into running downloaded malicious applications.
But we shouldn’t think of this as just an ever-escalating technical battle. Apple’s real goal with these changes, especially with the combination of the Mac App Store, sandboxing, and Gatekeeper, is to disrupt the economics that keep the bad guys in business, rather than fighting a never-ending series of one-off skirmishes.
As Uncle Ben said, “With great power comes great responsibility.” Apple’s moves toward a more-controlled (by Apple) experience on Mac OS X scare some users, and they could be problematic for many developers. The challenge for Cupertino will be to strike, and maintain, the right balance between control and freedom. That is, if they want to maintain the innovative heart that has made the Mac so appealing since 1984.
Let’s take a look at sandboxing, the Mac App Store, and Gatekeeper in particular, since they offer both the most promise for preventing attacks and the most risk for the soul of the Macintosh. I’m organizing this around answers to a series of questions — if you have additional questions, please ask them in the comments.
What is sandboxing? -- Practically speaking, sandboxing prevents applications from doing unexpected things to your computer. Sandboxing encompasses a set of techniques to isolate applications and minimize what they can do on your Mac. The idea is that some applications could harm your computer, either deliberately or if an attacker compromises them, and putting these apps in a “sandbox” limits the potential damage. A sandboxed application is allowed to interact with the rest of your computer only through a strict set of rules that specify what actions it can perform. Sandboxing has been around for a long time and is already in use in Mac OS X, Windows, and other operating systems.
Here’s a simplified explanation of how it works. A normal, non-sandboxed application has full access to everything on your computer, which can include reading and writing files anywhere on the file system, sniffing and sending network traffic, watching everything you type, controlling your camera and microphone, and more. (Technically speaking, the app is limited based on which protection ring it’s running in and what user account is active, but that isn’t important for this discussion.) Even if an app isn’t programmed to use all those capabilities, there is nothing in the operating system to limit what it can do. Thus, one of the most common ways to attack a computer is to find an application with a vulnerability, exploit that vulnerability to inject malicious code into the application, and then use the application to run the malicious code to perform further actions.
In contrast, a sandboxed application doesn’t run with full access. Instead, it executes inside a restricted container that is isolated from the rest of your Mac. Thus, if an attacker were to exploit a vulnerability in the app and inject malicious code, that code would be limited to the sandbox.
That might work for simple, standalone apps like casual games — Angry Birds could be sandboxed easily. But for more complex programs, sandboxing has some obvious problems, like saving files and accessing the network. To work around this problem, each individual application can be given a set of “entitlements” that allow the app limited access to other parts of your Mac. For example, a fully sandboxed app with no entitlements can save files only into its own directory, but with an entitlement, it can be given permission to save files anywhere in your home folder (which is still safer than the app being able to save a file anywhere on the file system).
iOS apps are heavily sandboxed, which is why apps can’t access each other’s files. iOS offers no entitlement to access shared files other than photos, so we’re forced to copy files from app to app using the Open In command.
This particular limitation in iOS, to be blunt, sacrifices usability for security. But at least most apps in iOS don’t create or manipulate documents (although that’s changing, thanks to the iPad). On the Mac, where far more applications are document-centric, and where the entire user experience revolves around the Finder, such a system would be a major disaster that would immediately drive every professional user to Windows. It would become impossible to use multiple apps to make changes to the same document without making a vast number of copies, and keeping track of which change was in which copy would be a nightmare. As a result, Apple has created more possible entitlements for Mac apps than for iOS apps, but sandboxed apps are still far more restricted than their non-sandboxed brethren.
The overall goal is the same — to ensure an application can’t do too much damage to your system, either by design or if it’s compromised by an attacker. But since the needs of Mac users are different than the needs of iOS users, it’s hard to figure out the right balance of restrictions and entitlements.
Why is sandboxing so important? -- Sandboxing is, to put it lightly, a very big deal. As operating systems have become harder to exploit (believe it or not, it’s pretty hard these days), attackers have started targeting specific applications. We see more attacks against Adobe Acrobat and Flash, Microsoft Office, Java, Web browsers, and QuickTime than we do against Mac OS X and Windows themselves. That’s why, for example, Apple now sandboxes parts of Safari and QuickTime, Google sandboxes Chrome, and Adobe sandboxes Reader and Acrobat (only on Windows).
Take Google Chrome. It is widely considered the most secure Web browser available, due to its heavy use of sandboxing. Chrome even embeds and sandboxes its own version of Adobe Flash to reduce the chance of a Flash exploit taking over a computer (Flash is notoriously problematic from the security perspective). I’ve seen very few real-world exploits that work on Chrome, and even fewer that break through Chrome’s sandbox, when Flash is the target. That’s why I uninstalled Flash from my Mac and view Flash-using sites exclusively with Chrome.
Sandboxing isn’t a panacea. Some entitlements may allow an attacker to do bad things outside the sandbox. Also, sandboxes themselves are software and may be cracked. But, at a minimum, the sandbox adds yet another layer an attacker has to get past before getting a foothold on your Mac, even if the application inside is vulnerable and exploited.
To put it bluntly, based on the nature of attacks today, sandboxing is likely the future on every computing platform.
What does sandboxing have to do with the Mac App Store? -- As of 1 June 2012, all new apps and major updates in the Mac App Store must be sandboxed.
Does this mean all Mac App Store apps are now sandboxed? -- No. All new apps are sandboxed, but existing apps aren’t necessarily. Apple says they will allow bug fixes to non-sandboxed apps, but not other upgrades. I also get the sense this is a fuzzy line, and some exceptions may be made (at least in the short term).
How will this affect apps? -- Some apps, if they wish to use sandboxing, will lose functionality that isn’t provided by existing entitlements. To get a sense of what entitlements are available to developers, check out Apple’s “Enabling App Sandbox” documentation. Apple also offers a set of temporary entitlements that developers may use only with permission, and that might go away in the future. Accessing the Movies folder is a regular entitlement, while accessing Apple Events (to enable AppleScript-based communication between apps) is a temporary entitlement.
The lack of certain entitlements and developer uncertainty about relying on a temporary entitlement have already affected some apps in the Mac App Store, with some developers eliminating functionality that’s impossible given current entitlement limits and others offering more-capable versions for sale outside the Mac App Store. For instance, Smile’s popular typing expansion utility TextExpander 4 isn’t for sale in the Mac App Store for this reason, while version 3.4.2 remains available there.
On the one hand, users suffer from the loss of functionality and from the confusion of multiple versions of apps, and either approach costs developers time and money. On the other hand, the sandboxing requirement enhances the security of all new and updated apps in the Mac App Store.
Why is Apple mandating sandboxing in the Mac App Store? -- Apple has learned a valuable lesson from iOS. There is currently no malware on iOS and we’ve never seen a widespread attack. Contrast this to Google Play and especially the non-Google-supported Android stores, which are riddled with Android app malware. Apple’s App Store requires sandboxing and reviews all apps; Google Play (and the alternative markets) place no such requirements on developers. Apple’s strict control over the App Store provides the safest user experience out there, and while you may not think about it consciously, the fact is that you don’t have to worry about malware in the App Store doing bad things to your iPhone or iPad.
We see Android cybercriminals using the same techniques they’ve successfully relied upon to exploit Windows users, such as hiding Trojan horses in versions of popular applications, pretending to be security apps, and drive-by downloads.
Even if someone manages to sneak a malicious app into the App Store (as some researchers have done with proofs of concept), or an app is later compromised and used in attacks, Apple could remove it and stop all new infections. (Apple doesn’t uninstall apps from iOS devices, although they could do so with a software update in a really bad situation).
Apple wants to provide this same experience to users on Macs and give us a safe place to buy and install applications. They may not market that as a benefit of the Mac App Store explicitly, but they want security to effectively disappear as a concern for users.
Can bad guys break out of the sandbox? -- Probably. Then Apple will harden it again. Then the bad guys will break it again. And so on. No technology is perfect, but sandboxing most definitely raises the costs of attacks. In fact, it so significantly raises the cost of attack that it wipes out entire classes of potential bad guys who lack the technical skills or budget to target and crack the sandbox.
Is there a downside to mandating sandboxing? -- Absolutely. Not every application can meet the sandboxing requirements. Macs are general-purpose computers, and by definition, that means that developers can come up with innovative applications that can do things — and need to do things — that Apple has not anticipated and for which there are no entitlements.
Some apps will never be able to be sold in the Mac App Store. This is a problem since, as more users go to the Mac App Store for their apps, it may become economically difficult for those developers to reach a large enough audience.
We don’t know how this will play out in the long term. My hope is that as the overall Mac market share increases it will create more opportunities for both Mac App Store and independently sold applications, offsetting the inability to sell non-sandboxed apps in the Mac App Store. This is clearly an optimistic view, and it’s also entirely possible that the market for smaller developers whose apps can’t be sandboxed and sold in the Mac App Store could shrink to the point of driving them out of business.
Apple also faces criticism, especially from developers, related to other Mac App Store problems (such as unpredictable and poorly supported rejections, the lack of demos, the inability to communicate with customers and respond to user reviews, and more). Mandating sandboxing without addressing these other complaints has increased developer concern and uncertainty, and connected Mac App Store policies and sandboxing in a way that I fear could hurt the perception of this valuable security technique.
Why not make sandboxing optional? -- In my experience, optional security is non-existent security. Microsoft has offered sandboxing capabilities for years and practically no developers use them. Microsoft even struggles to get developers to adopt anti-exploitation technologies like ASLR or EMET, despite the fact that there is basically no cost in doing so because the technologies are built into development tools. Heck, it took Microsoft years to convince Apple to enable ASLR for its Windows applications.
Apple wants the Mac App Store to be as safe as possible. Maybe it’s for marketing, maybe it’s for altruism, but the motivation doesn’t matter if the results improve our safety. Based on past history, if Apple doesn’t mandate sandboxing, nearly no developers will likely use it. I hate to word it that way, but I’ve been in the security game for a long time and all my experience, and that of other security professionals, says that, without a stick, only a few horses will eat the carrot.
Does Apple sandbox their own apps? -- Not those sold in the Mac App Store. And, to be honest, it would really help their case with developers if Apple would follow their own rules. It would also help Apple better understand developer concerns and improve entitlements if their own teams had to work within the same restrictions. Perhaps they are moving in this direction internally, but the current versions of Apple’s major applications in the Mac App Store (including Aperture, Final Cut Pro, iLife, and iWork) are not sandboxed.
Aside from the poor example this sets, you have to assume that the bad guys are also working to target Apple’s applications — after all, iTunes is nearly ubiquitous on Macs, and if it’s not sandboxed, that makes it all the more attractive as a conduit for malware. iPhoto is probably next on the target list, with GarageBand, Pages, Keynote, Numbers, and the professional apps coming in behind.
Will Apple grant exemptions to any apps or developers? -- Possibly, though if this has happened so far, no one is talking. I get the impression Apple’s policy-makers are still feeling their way around, at least internally. (Developers report that any queries about exemptions that aren’t already covered by entitlements are met with resounding silence from Apple.) We’ll need to see if they grant exemptions to sandboxing for any major or innovative developers, but right now the rule is hard and fast. All I can say is that, in my discussions with Apple, I sense that the sandboxing requirement and entitlement list isn’t as final as, say, killing off floppy drives.
Where does Gatekeeper fit in? -- Gatekeeper is a new feature in Mountain Lion that enables you to restrict what kind of downloaded applications will run on your Mac. While Apple has designed the Mac App Store and the sandboxing requirement to give users a safe place to buy apps, Gatekeeper is designed to strike at the economic heart of cybercrime.
By default — and most people won’t change this setting — Gatekeeper will allow only two types of downloaded apps to launch on a Mac: those from the Mac App Store, and apps that are digitally signed with an Apple-issued Developer ID.
One of the most common ways to get malicious software onto someone’s Mac is to trick them into downloading and installing it. Criminals use sophisticated techniques that often fool knowledgeable users and even security pros, not just less-experienced users. By preventing downloaded software from launching unless it comes from the Mac App Store or a known developer, Gatekeeper closes the door to this approach to infection.
Bad guys will undoubtedly try to bypass Gatekeeper by, for example, stealing a legitimate developer’s Developer ID, but once again, the addition of Gatekeeper makes it much harder to produce malware that could spread widely, and thus reduces possible profit.
How does Gatekeeper work? -- I covered Gatekeeper’s features in depth in “Gatekeeper Slams the Door on Mac Malware Epidemics” (16 February 2012), but here is a quick summary:
Gatekeeper enables you to restrict which downloaded applications can launch on your Mac. There are three possibilities: Mac App Store only, Mac App Store plus Developer ID-signed applications, and no restrictions. The default is to allow Mac App Store apps and Developer ID-signed apps.
Gatekeeper checks only applications downloaded using programs (like Web browsers) on a list Apple maintains. Thus not every downloaded file is quarantined, nor are files transferred using cloud-storage services like Dropbox, USB flash drives, CD/DVDs, or other media.
You can override Gatekeeper and run any arbitrary application by Control-clicking it and choosing Open, but this command is intentionally concealed to make the process non-intuitive and, at minimum, to make the user realize something strange is going on. Apple has purposely made it more difficult than merely clicking an Open Anyway button in a dialog, since we users have a tendency to click whatever appears.
Gatekeeper checks downloaded applications only the first time they run. And, of course, since it checks only downloaded apps, it won’t check any already installed applications when you upgrade to Mountain Lion.
There’s a lot more to Gatekeeper, but the main thing to know is that once you upgrade to Mountain Lion you won’t be able to run newly downloaded applications that aren’t from the Mac App Store or signed with a Developer ID unless you jump through a few extra hoops.
Are most developers using Developer IDs? -- Not yet, but adoption is growing quickly, according to my sources at Apple. Major publishers like Adobe are issuing updates for their applications, and I know many of the smaller apps I use regularly have been updated with a Developer ID. If you’ve been following the updates we publish in the TidBITS Watchlist, you’ll notice that we’ve been mentioning when developers are signing their apps in order to support Gatekeeper.
How does restricting where my apps come from improve security? -- Most users never change the defaults on their Macs. As we’ve already discussed, limiting which applications can launch to those that come from the Mac App Store means you’re getting only apps that are vetted by Apple. Many of those are also sandboxed; eventually all will be.
But, as we’ve also discussed, not all programs can meet the Mac App Store’s sandboxing requirements. Had Gatekeeper drawn a distinction between only those apps in the Mac App Store and those not in it, a large percentage of users would have opted for no restrictions, since it would have been too frustrating to deal with applications downloaded from other sources. The beauty of allowing Developer ID-signed apps to run by default is that we can still install most legitimate apps with no fuss, but Apple maintains control at a developer level rather than an application level.
Members of the Mac Developer Program (which costs $99 per year) can use their free Developer IDs to sign whatever they want, and Apple doesn’t review signed apps. However, should a signed app be discovered to be malicious, Apple can place that developer’s certificate on a blacklist and Gatekeeper will prevent additional users from installing any apps from that developer.
This technique could dramatically reduce the spread of malware. Even if a criminal manages to get, or steal, a Developer ID, the moment they are discovered and Apple blacklists that ID, the malware is prevented from spreading on any more Gatekeeper-enabled Macs.
Gatekeeper isn’t a perfect security control, and it isn’t meant to be. By focusing on widespread attacks Apple is reducing the economic viability of Mac malware spread by tricking users into installing bad things. Combine this with the increased hardening to reduce exploits of the Mac itself, and it becomes much more expensive to attack Macs.
(And yes, developers should seriously protect their Developer IDs, since if a Developer ID is stolen and used in malware, Apple’s blacklist would also apply to all legitimate software signed with that Developer ID, causing an immediate drop in sales and a serious reputation hit. Apple has a poor track record in working with developers to address problems, so I can imagine quite some time passing before such a situation could be resolved.)
What worries users and developers about these security technologies? -- In a word, iOS, which shows both the benefits and the risks. We have never before seen these sorts of restrictions on our general-purpose Macs, but we have seen them in action in iOS, where there are notable limitations on what can be done (the lack of a centralized file system is a notable example) and where Apple has regularly misused its role as gatekeeper.
The limitations imposed by sandboxing have developers worried that they either won’t be able to innovate freely and exist within the Mac App Store’s sandboxing requirements, or that they won’t be able to reach a large enough market outside the Mac App Store to justify development costs. Developers are also worried that, as we’ve seen in the iOS App Store, the rules will change or that Apple simply won’t abide by them. There are multiple cases of Apple behaving capriciously, rejecting otherwise legitimate apps without reason. For developers to invest the significant time and money into development, the marketplace has to be run in a fair and aboveboard manner. Without consistent rules, markets can’t survive.
I’ve also talked with lots of developers and power users alike who worry that Apple wants complete control over what we run on our Macs. They worry that Apple will, in the future, mandate that everything go through the Mac App Store and be sandboxed, or that so much of the market will rely on the Mac App Store that there will be no way for software to survive outside of it. The concern is that the end result may be more safety for the average user, but at the cost of freedom — and advanced capabilities — for professional users.
I may love my iPad, but I equally love all the wonderful tools and tweaks of my Macs, many of which wouldn’t be possible in a completely sandboxed world.
I can’t predict the future, but my personal feeling is that the current team at Apple recognizes the differences between a general purpose computer and an iOS device. The fact that they created the Developer ID instead of merely using Gatekeeper to force the use of the Mac App Store is a sign that they want to balance freedom and safety. Apple has also expanded sandbox entitlements, although calling them “temporary” makes any company relying on them wonder when the rug will be pulled out.
If there is one thing I hope Apple learns if they read this article, it’s that users and developers may appreciate the safety of this strategy, but they very legitimately fear where we may be headed if Apple exercises too much control. Sandboxing and the Mac App Store are so interconnected that if sandboxing is perceived as a tool to control the overall user experience versus protecting users, it will negatively affect perceptions. Apple is big enough and powerful enough to do whatever it wants, but going to the logical extreme would be a harsh blow for those users most invested in the Macintosh way, to reference Guy Kawasaki’s first book (now available as a free download).
While I don’t personally think that Apple wants the Mac to become as locked-down as an iOS device, we all need to admit it is a legitimate concern, considering how much of iOS has made its way into Lion and how much more is coming in Mountain Lion.
As someone who lives in the security world, I think Apple is moving in the right direction, albeit with room for improvement. These security technologies and techniques have proven effective in targeting the big picture problems, and I suspect Microsoft will need to adopt similar ecosystem approaches as they move into Windows 8 (which is already inherently quite secure). But I hope Apple recognizes why so many experienced users and developers are concerned, and some clearer communication might assuage at least a few of those fears.