Sandboxing from a SELinux/Mac developer

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.

Technical issue

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.

Recommendations

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.

Comments

9 comments

Zach

Friday, November 4, 2011

I would add that client-side attacks are where all the new hawtness is. Getting a user to open a malicious file in a vulnerable application has become a very common way of getting a foothold on a well-defended network. Even if your application isn't targeted directly, vulnerabilities in the core APIs it uses are transitive. I would also add that if Apple creates a tool to check the sandbox policies, they should call it "checkpolicy".

Chad Sellers

Friday, November 4, 2011

The new hotness where? I've never seen a single article about a Mac user being attacked by opening a malicious document in anything other than a browser. Perhaps I'm just out of the loop, so I'd love to see what I'm missing.

Joshua Brindle

Friday, November 4, 2011

I agree with Zach. It doesn't matter if it is only the browser (especially since the browser can open dozens of different types of documents). Spear phishing is probably one of the biggest threats to individual users (which includes Mac users, on single-user systems) and the information would-be intruders are after is available as the user running the browser, no escalation required. As you know, the whole point to flexible MAC is to separate user intentions from applications, because the applications are too big and complex to know what they are doing. This will all be rendered moot when everything is on the web, err cloud, and compromising the browser gets you all the data you want, without leaving a restrictive local sandbox (oops).

Zach

Friday, November 4, 2011

I don't disagree with you that Macs currently aren't frequently targetted. I really was countering the part (that I inferred) about Macs being targetted less frequently than Linux because they aren't often used as servers.

Chad Sellers

Friday, November 4, 2011

Josh - It does matter that it's only the browser. If it's only the browser, then the browser is where you should target your efforts. Just as Red Hat (after the Fedora Core 2 fiasco) chose to target SELinux at the things that were most under attack, rather than confining every random little user app in yum that no one would ever attack. I'm not saying this doesn't protect against potential attacks. I'm just saying no one is using these attacks because they're much harder than throwing a fake site on the web and getting people to download and run a Trojan (MacDefender). Mandating Mac App Store apps be sandbox doesn't help with the real problems users are facing today.

Chad Sellers

Friday, November 4, 2011

Zach - Yeah, I had a bit more about the server part, but cut it for brevity sake. The reality is they are used as servers, but not using App Store apps. To your point, I did find some things regarding malicious MS Office docs. Ironically, the apps most likely to be targeted with malicious documents are the ones that will likely never be sold through the App Store.

Joshua Brindle

Friday, November 4, 2011

@Chad I'll grant you that isolating 3rd party apps while having privileged, but non-isolated 1st party apps is a recipe for disaster. It is how practically every iOS and Android exploit today works. As a counter point to why platform controllers (in this case Linux distro's but Apple as well) need some understanding of what/why applications need permissions see the recent Calibre discussion https://bugs.launchpad.net/calibre/+bug/885027 (I don't know how to make real links on in your comments...)

Chad Sellers

Saturday, November 5, 2011

Josh - Safari actually is sandboxed (quite well), but that doesn't stop a user from downloading a malicious application and installing it (MacDefender which made headlines this year actually had an installer that users had to click through). And since sandboxing is opt-in, the downloaded malicious app will obviously not do so, giving it full user access. Oh, and I did see the Calibre discussion, which is pretty hilarious.

Jeanette

Wednesday, April 4, 2012

cool!