Friday, November 4, 2011
Who am I
I'm in a unique position with regard to the current Mac App Store sandboxing debate. I'm a Mac app developer who, until recently, was an SELinux developer. SELinux is a Linux access control mechanism that can confine applications in a similar way to Apple's sandbox mechanism. So, I've been on both sides of this debate.
A bit of history
To understand some of the problems with the current sandboxing mechanism for apps on OS X, it's important to understand the basics of the history of sandboxing on OS X. The story actually begins with SELinux. SELinux is an access control mechanism that lets you control all application interactions on a Linux system. You do so by writing a policy. These policies can allow anything at a very fine grained level. Consequently, they are known for being complicated, which has long been SELinux's biggest black eye. People complain that it's too hard to use, and many application vendors simply recommend turning SELinux off rather than taking the time to write a policy to make their application work.
Despite its complications, SELinux was a giant step forward in securing systems, and many people quickly wanted similar functionality in other systems like Mac OS X. So, some guys started working on adding similar capabilities to FreeBSD and Darwin (Mac OS X's open source core). They created the MAC Framework (MAC here stands for Mandatory Access Control), which allows enforcing these sort of access controls. They then built SEBSD and SEDarwin on top of the MAC Framework to allow developers to create SELinux-like policies on FreeBSD and Mac OS X.
Apple then took this work and incorporated it into Mac OS X. I am not privy to how it went down inside Apple, but they ended up taking the MAC Framework but deciding not to use SEDarwin. Instead, they built their own policy engine, which was initially called seatbelts before being renamed to simply sandbox. This was released as part of Leopard in 2007, though it was not used very much then. Users and developers could then sandbox their applications, and even write flexible sandbox policies tailored to their application (though I'm guessing I'm one of the only people to do so).
The big change in Lion is the addition of sandbox entitlements. Entitlements are abilities that an app can say it needs. The system will then create a sandbox policy for the application to run inside of based on the entitlements requested. Lion includes a short list of high-level entitlements which map to sandbox rules. My guess is that Apple decided that writing sandbox rules would be too complicated and error-prone for developers, so they made entitlements as a simple checklist abstraction on top of sandbox rules.
Much of the debate about sandboxing Mac App Store apps centers around the many apps that cannot work within sandboxes or that will have to drastically change their core functionality to do so. This is not a fundamental flaw in sandboxing. You could write a sandbox policy for every application out there. The problem is that Apple's entitlements abstraction is not nearly as flexible as the underlying sandbox mechanism. This prevents huge numbers of apps from working with sandboxes today.
This limitation is not surprising at all. On the SELinux side, I worked on several large efforts to create simpler abstractions on top of SELinux policy. They all failed in one of two ways. The first way they failed was to be deemed too inflexible to work with a large percentage of applications and consequently they never gained traction in use. The second was they failed was to gradually expand the abstraction to create flexibility until it eventually ended up as complicated as the underlying system it was supposed to abstract. I'm not sure where Apple will go in the long run, but I see elements of both in the current entitlements system.
Why are we doing this?
It's clear that the sandbox mandate will have a huge effect on applications, but is it really going to help the security of Mac systems? I can easily make a case for why confining Linux applications with sandboxes makes sense. Linux is frequently used in server systems, and the applications running on those servers are constantly under attack. Web servers, mail servers, etc. regularly have exploits run against them. Confining these applications can protect them and their underlying system.
Mac apps, on the other hand, are not under attack. The few attacks that exist target the operating system itself or the web browser. Confining third-party applications won't protect against these attacks. If Apple manages to lock down OS X itself well enough that attackers start to target third-party apps, this move might make more sense. However, today the obvious attack vectors in OS X are all going after Apple software, so attackers won't waste their time with third-party apps.
My first recommendation would be to do away with the mandate. There's just not enough of a reason to do this right now. Computer security is all about determining risk and appropriate responses. The risks are too low to justify this large a mandate.
I assume Apple won't take my first recommendation, so I have a fallback. I don't believe the entitlements mechanism will ever be flexible enough for a huge percentage of Mac apps. So, I'd love to see an option to forego entitlements and instead write your own sandbox policy. This would give developers the flexibility they need. Apple could easily create automated policy analysis tools to flag developer policies that were dangerous or against the App Store guidelines. It would be more complicated for developers that chose to write their own policy instead of using entitlements, but that's better than being forced out of the App Store entirely.