Tag Archives: Sandboxing

Open Question: Which MacOS apps will be broken by sandboxing?

There were some quick responses to this morning’s post about the App Store. I immediately wished I’d at least mentioned the awkward transition the Store is going through right now. Apple is demanding basic changes to the way that apps operate. It’s called “sandboxing” and it’s designed to ensure that no app, either through malice or incompetence, can interfere with any system process or anything that any other app is doing.

Which isn’t a bad goal. It’s very user-positive. But keep in mind that Mac developers have been building apps any way they like since 1984. Many apps use techniques that are perfectly harmless, but impossible to implement under sandboxing. Other apps are designed to deliver a basic, system-wide function that’s fundamentally incompatible with the concept.

I’ve been aware of this for a while and have written and spoken about it frequently. But I only just now realized that I’ve never seen a public list of apps that are broken by sandboxing. Yes, it doesn’t mean the end of the app — users can still sideload it outside of the App Store — but it does cut the app off of Apple’s “blessed and trusted” mechanism for purchasing, installing, and updating safe apps.

I will quickly categorize three standout types of “broken” apps:

1) An app that fundamentally can’t function in a sandboxed environment. Generally, system apps that do something Wonderfully Clever. It can’t work, so it won’t be updated.

2) An app that uses a Clever Trick as a shortcut. Developer will finally sit down and figure out how to make that function work within the new rules.

3) An app that’s simply old and in its “dividend” phase. Maybe it doesn’t work because of a shortcut, maybe it doesn’t work because it hasn’t been updated to completely use the modern framework. It’s not that there are any technical barriers to making it work under the new system, but at this point in the app’s life it generates enough revenue only to support simple bugfixes, and not top-to-bottom rewrites. Developer shrugs, thinks “Okay, my Austin Powers Talking Clock had a good run and now it’s time to move on” and the app dies.

I am literally minutes away from leaving my house for an unbreakable appointment (or else I’d do an exhaustive search to see if such a list already exists).

Still, I thought I’d leave an open question:

1) Do you know of an app whose future is put in jeopardy by sandboxing? (Ideally: an app that you wrote)

2) Is it so bad that there’s a real risk that the app will be frozen in its pre-sandboxed state?

Leave responses in comments.

Apple Revamps Security in OS X Lion | threatpost

Short, plain-English article explaining the security upgrades in Lion. As we speak, Apple developers are building new versions of their apps to support sandboxing.

“OS X has always had this goofy ASLR implementation where the randomized the libraries but not anything else, and you could still play the games and reuse code as long as there was one thing that wasnt randomized,” said Charlie Miller, principal research consultant at Accuvant, who does a lot of OS X security research. “In Lion it seems like everything is randomized and no code is loaded at a predictable address. They made it much harder to exploit things. You probably need two bugs now, one for code execution and one for information disclosure.”

via Apple Revamps Security in OS X Lion | threatpost.