Apple’s Sandboxing Nontroversies

| Editorial

So, a story tailor-made for the “blogosphere” hit recently, of the new version of TextExpander 4, and how it’s a “victim of sandboxing.” (If you say that like you’re an 80-year-old southern belle reaching for her hankerchief and fainting couch, you get the general mood of things.)

I find all this somewhat amusing and depressing because all I can think is “…and you’re SURPRISED by this?” If you have even a conceptual grasp of sandboxing, the fact that TextExpander’s new version won’t be in the Mac App Store should be about as surprising that one won’t find daisies growing in a tar pit. But first, let’s see a tl;dr explanation of sandboxing:

App Sandbox provides a last line of defense against stolen, corrupted, or deleted user data if malicious code exploits your app. App Sandbox also minimizes the damage from coding errors in your app or in frameworks you link against.

Turns out not everyone is happy with Apple's sandboxing rulesTurns out not everyone is happy with Apple’s sandboxing rules

So okay, sandboxing is designed to protect against malicious code exploiting an application. For example, by reaching into another application’s process, and oh, I don’t know, monitoring everything the human types, and taking predermined action if the “right” thing is typed. Now, if you’re an awesomely cool dev like Smile Software, there’s no harm. You type, say “mosx” and poof! “Mac OS X” appears on your screen. Handy, no?

But if you’re an evil dev, then you look for things like phone numbers or numbers separated by a ‘random’ dash or space, or the heck with it, just copy everything typed, and send it out to a server somewhere.

So what’s the difference, other than intent and use of the data? Well, nothing. The same technique can be used for good or ill. For example, I’m in IT. I use a number of tools for things like security scanners that allow me to see if there are any holes in my setup, so I can patch them. But a black hat using those same tools would do very different things with that data. For me, it’s something to be fixed. For them, something to be exploited.

The point is, for any OS to play “good code/bad code” is a fool’s game. There’s no such thing. There’s stuff that’s allowed, and stuff that is not. Sandboxing obviously increases the latter and decreases the former, and one of the specific reasons is to keep applications out of each other’s business. This is not a theoretical risk mind you, there’s already been a bit of malware that took advantage of earlier implementations of OS X’s Input Manager to spread itself about.

This was in the OS X 10.4 days, which is why Apple changed how Input Managers worked starting in 10.5. Fortunately, this trojan/worm, Leap-A, aka “Oompa-Loompa,” didn’t do any damage other than keeping infected applications from running — which ironically slowed its ability to spread — but still, it’s a useful data point that shows what one person can use for good, someone else can use for ill.

That’s what Sandboxing is about: keeping application A out of application B outside of a specific set of defined entitlements. To be honest, there’s not a real problem for most applications. Most applications just don’t care about twiddling inside of other application processes.

Most applications are happy to limit their ‘external’ interactions to user-initiated ones, like saving, opening, printing, and maybe some automation via scripting. (Scripting is also affected by sandboxing, but that’s a tale for another time.)

In fact, looking at my dock now, I see, out of over 50 applications, maybe five that need to reach out and touch other applications the way Smile Software’s TextExpander does, and one of them is TypeIt4Me. (I’m old skool, sue me.) For most applications, sandboxing is really not an issue, they either never need to reach out and touch other applications, or, they do so in ways that are easily defined and so specific entitlements can be used. (Microsoft Office is a good example here.)

However, you do have applications that are affected by sandboxing. Like TextExpander. Face it, there’s no way to do entitlements, because Text Expander would need one for everything. It’s supposed to work in every application you run. If you’re going to grant a God Mode entitlement, why even bother with sandboxing at all?

Apple even has some basic guidelines for applications to determine if they can play in a sandboxed world, in the App Sandbox Design Guide. This includes:

  • Use of Authorization Services. With App Sandbox, you cannot do work with the functions described in Authorization Services C Reference.
  • Use of accessibility APIs in assistive apps. With App Sandbox, you can and should enable your app for accessibility, as described in Accessibility Overview. However, you cannot sandbox an assistive app such as a screen reader, and you cannot sandbox an app that controls another app.
  • Sending Apple events to arbitrary apps. With App Sandbox, you can receive Apple events and respond to Apple events, but you cannot send Apple events to arbitrary apps. By using a temporary exception entitlement, you can enable the sending of Apple events to a list of specific apps that you specify, as described in Entitlement Key Reference.
  • Sending user-info dictionaries in broadcast notifications to other tasks. With App Sandbox, you cannot include a user-info dictionary when posting to an NSDistributedNotificationCenter object for messaging other tasks. (You can, as usual, include a user-info dictionary when messaging other parts of your app by way of posting to an NSNotificationCenter object.)
  • Loading kernel extensions. Loading of kernel extensions is prohibited with App Sandbox.
  • Simulation of user input in Open and Save dialogs. If your app depends on programmatically manipulating Open or Save dialogs to simulate or alter user input, your app is unsuitable for sandboxing.
  • Setting preferences on other apps. With App Sandbox, each app maintains its preferences inside its container. Your app has no access to the preferences of other apps.
  • Terminating other apps. With App Sandbox, you cannot use the NSRunningApplication class to terminate other apps.

Apple has clearly anticipated classes of applications that are not compatible with sandboxing. Does that mean they can’t run on Mountain Lion? No. What it really means is that a new versions of a non-sandboxed application can’t live in the Mac App Store. You can make bug fixes to existing non-sandboxed applications, but a new verison or updates that aren’t bug fixes? Nope, no Mac App Store for them.

Is this, as some have painted it, some kind of trend that could cause scads of developers to leave the App Store? Hardly. Again, the number of applications that actually cannot work within sandboxing are small compared to the overall population. The Mac App Store isn’t for them. Should Apple grant, as Harry C. Marks suggested, a “special” license for approved developers like Smile to bypass them? No. The point of security is that exceptions are very rare, and preferably, never issued. Yes, it sucks that a group of really good people like Smile had a product affected by this.

But it was going to happen. If not to them, then to someone else. Security is no longer something that only happens on a firewall. It’s everywhere.

Sandboxing is an important part of overall improved security without things like unusable passwords, anti-malware scanners, and the like. Sandboxing is something that protects people who don’t know how this stuff works or why. It’s for people like my father-in-law, who is a friggin’ genius at things like building houses, but doesn’t want to have to care about his computer. He just wants stuff to work, and if he can get that and never have to pay Symantec or Sophos another dime in his life, he’ll be just fine with that.

This is not Apple giving Smile the middle finger. This is Apple saying “If you want to be in the Mac App Store, you have to play well with sandboxing. If you don’t, you can still be on the Mac; OS X is not iOS. But you can’t be in our store.”

Apple is doing this for the huge number of Mac users who will never get on a Mac blog, or website, or ever comment about any of this. They’re doing it for the vast majority of their customers who just want stuff to work, be safe, and trust the Mac App Store to be a source of safe applications. Unfortunately, security is pain. The more security you have, the more pain you have. That expectation of safety means that there are kinds of Apps that simply can’t be in the Mac App Store.

For edge case applications like TextExpander, the Mac App Store isn’t a place they are compatible with any more. It’s a shame, but it’s not some great OMG, ALL MY APPS ARE TEH DEADZ0R!!!! It’s just the consequences of security becoming more important.

[Some images courtesy Shutterstock.]

Sign Up for the Newsletter

Join the TMO Express Daily Newsletter to get the latest Mac headlines in your e-mail every weekday.

Comments

Bosco (Brad Hutchings)

It is interesting to see that ball waxing is an Olympic sport this year. My question for the author is whether the team wears shorts and tanks or red, white, and blue leotards.

Ultimately though, the author fails to address the main criticism of this whole scheme. And that’s the message that Gatekeeper gives to the precious stupid users. Does it imply that signed apps downloaded from other sources are less secure or less expertly coded that apps that appear in the MAS? Do these stupid users get an even worse impression of apps whose developers don’t want to pay Apple’s $100/year security ransom? Or… might even the stupid people using Macs quickly figure out that Gatekeeper is a sham designed to help Apple take 30% of all software sales on the platform? My money is on the latter, which is why the ball waxing exercises are ultimately unhelpful to most Mac users.

John C. Welch

It is interesting to see that ball waxing is an Olympic sport this year. My question for the author is whether the team wears shorts and tanks or red, white, and blue leotards.

Ultimately though, the author fails to address the main criticism of this whole scheme. And that?s the message that Gatekeeper gives to the precious stupid users. Does it imply that signed apps downloaded from other sources are less secure or less expertly coded that apps that appear in the MAS? Do these stupid users get an even worse impression of apps whose developers don?t want to pay Apple?s $100/year security ransom? Or? might even the stupid people using Macs quickly figure out that Gatekeeper is a sham designed to help Apple take 30% of all software sales on the platform? My money is on the latter, which is why the ball waxing exercises are ultimately unhelpful to most Mac users.

a) I don’t think non-technical users are stupid. They just have no interest in how their computer works any more than the majority of drivers have for their transmission. They use the computer to get stuff done, preferably without having to worry about “will this program blow me up”.

b) Gatekeeper is not sandboxing. You don’t have to sandbox at all to play nice with Gatekeeper. Gatekeeper can work with sandboxing, but doesn’t require it. Non-MAS applications still can play with Gatekeeper. But nice strawman.

Also, good job on slagging 99% of mac users as being stupid because they don’t care about twee details. They would of course, be the ones making Apple all its money.

Nom

Worth noting that what apps like TextExpander do is inherently insecure and dangerous - we just happen to trust them.  Short of Apple manually vetting all behaviour in each such app, there’s really no way around the issue.  Inter-app communication is only secure if the receiving app sanitises all inputs.  And if an app is allowed to access and modify data in another app, there’s no way that can be secure unless the target app explicitly provides this interface.

Bosco (Brad Hutchings)

For users that have chosen MAS apps only—the highest security setting, developers must sandbox. See transitive property of equality. Then there’s the ransom level of security (MAS + identified developers) that only checks the developer certificate the first time the app is launched.

On one hand, Apple is acknowledging that malware is an issue on the platform. On the other, its solution is a self-serving single source store and half-assing the alternative. Meanwhile, the cheerleaders decry the false alternative of having to pay for and install bloated AV like Norton, when the Microsoft Security Essentials is free, just as effective, totally unobtrusive, and not difficult for normal people to deal with. And it uses pattern matching of software activities to detect malware rather than rely on a famously arbitrary store approval process and certificate security.

And for the record, I definitely don’t think Mac users are stupid. This arrangement treats them like they are.

Frank

If you want to read a more intelligent and less biased article on sandboxing check out Andy Ihnatko’s excellent article:

http://ihnatko.com/2012/06/26/icloud-and-app-store-transition-yojimbo/

John C. Welch

For users that have chosen MAS apps only?the highest security setting, developers must sandbox. See transitive property of equality. Then there?s the ransom level of security (MAS + identified developers) that only checks the developer certificate the first time the app is launched.

That’s a user choice, it’s not the default from all available information. At that point, I’m still not calling them stupid. Also, you seem to be unclear about how Gatekeep et al work. You might wish to read up on it more.

On one hand, Apple is acknowledging that malware is an issue on the platform. On the other, its solution is a self-serving single source store and half-assing the alternative

Really? A single source for software on the store? What source is that brad? All software on the store is from Apple? I think not. Or perhaps you mean “Only MAS applications will work in Mountain Lion”? There’s no value of “correct” that applies to either of those interpretations, so I’ll just put those down to your usual handwaving and attention-mongering.

Meanwhile, the cheerleaders decry the false alternative of having to pay for and install bloated AV like Norton, when the Microsoft Security Essentials is free, just as effective, totally unobtrusive, and not difficult for normal people to deal with.

Microsoft Security Essentials is most definitely not as effective as full on anti-malware. If it were, why does windows scream about being “not fully protected” if that’s all you have. (DO keep in mind, I run windows and linux boxen too. I’m on firm ground here.) If Microsoft Security Essentials is “all you need” then why does the OS say different? Oh, and a few people would disagree with your assessment on the efficacy of MSE, including PCMag, not a noted anti-MS shill:

http://www.pcmag.com/article2/0,2817,2403986,00.asp

Pertinent quote from the review:

Microsoft Security Essentials detected 63 percent of the threats, lower than any product tested with the current or previous set of malware samples. It left behind executable files for more than half of those it did detect, and several of them were still running after their alleged removal. Its overall score of 4.3 points for malware cleanup is the lowest of any current product.

40 percent detection of rootkit samples is also a new low. However, Microsoft thoroughly cleaned up all the rootkits it did find, scoring 4.0 points. Quite a few products tested with the previous malware collection scored lower, despite higher detection rates. Even so, I wouldn’t rely on Microsoft to clean up a malware-infested system.

Looks like MSE isn’t “all you need”. Oops.

Also, anti-malware software, by definition, cannot be “unobtrusive”. It can be smooth in operation, but it is always going to slow things down, that is, if you want it to actually look for and halt malware. If you just want it installed, but not actually doing anything, well then, why even have it? Maybe you enjoy false senses of security, but I’m in the “that’s stupid” camp on THAT topic.

it uses pattern matching of software activities to detect malware rather than rely on a famously arbitrary store approval process and certificate security.

You mean a famously arbitrary list of software patterns that is defined by the antimalware vendor, and therefore limited in effectiveness depending on the quality of the list and the timeliness of the updates?  Seems kind of “arbitrary” to me, especially given past tests that show not all antimalware is created equally.

And for the record, I definitely don?t think Mac users are stupid. This arrangement treats them like they are.

Thus far, you’ve not done a stellar job of proving that point.

John C. Welch

If you want to read a more intelligent and less biased article on sandboxing check out Andy Ihnatko?s excellent article:

http://ihnatko.com/2012/06/26/icloud-and-app-store-transition-yojimbo/

First, thanks for the ad hominem. I feel so warm by the dint of your telepathy.

Second, Andy raises some good points, but he makes some assumptions that I disagree with, mostly that Apple is never going to change any of these policies. While I get the “APPLE NEVER CHANGES ITS MIND” meme is certainly popular, it’s not supported by actual facts.

Log-in to comment