Print 13 comment(s) - last by B3an.. on Nov 6 at 6:57 AM

For small apps changes aren't any big deal, but for big apps Apple's new mandatory sandboxing could be game over

Great American statesman Benjamin Franklin once wrote, "They who can give up essential liberty to obtain a little temporary safety, deserve neither liberty nor safety."

While he certainly wasn't talking about personal computers, that's exactly the dilemma PC makers find themselves in today.  After all, allowing apps full system liberties opens a world of intriguing new possibilities -- but also new dangers.

I.  Apple Backs Mandatory Sandboxing on the Personal Computer

Some are voicing support for sandboxing, the idea of preventing apps from "talking" to each other, accessing folders outside their own, executing shell commands, or using the attached hardware (without explicit permissions).  So far only one company has embraced such an approach for its personal computer -- Google Inc. (GOOG), makers of Chrome OS.  But sandboxing is about to get a big new proponent as Apple, Inc. (AAPL), the third largest maker of PCs in the U.S., is about to roll out the feature on March 1.

For apps that are distributed in retail form or over the internet, developers -- for now -- won't have to comply with the sandboxing restrictions.  But sandboxing will be mandatory to all new apps in the Mac App Store.  Developers will also have to change their existing Mac App Store apps to sandboxed form if they want to post an update.

Under Apple's new sandboxing system apps will be able to request "entitlements", such as access to a web camera, access to USB devices, access to special folders (music, downloads, etc.).  While this is similar to how sandboxing is handled in Google's Android operating system, Apple will take things a step further and decide whether the requested entitlements are appropriate as part of the applications submission process.

The new security features will help prevent malware, like the recent wave of trojans sweeping Apple's computers [1][2].

Apple wrote developers "the default sandbox environment is as simple as checking [the right] checkbox" in their development environment.  For simple apps, that indeed may be all the intervention that is needed in order to assume compliance with the new restrictions.  But for power apps, deep debugging, testing, and recoding may be required.

II. Developers Aren't Happy

Developers are upset because they fear that customers won't understand the changes and will simply blame them from removing features which can no longer be implemented under the sandboxing regime.  

Some developers are also frustrated at the timing of Apple's decision.  They are used to dealing with changes when there's an operating system release, but aren't used to having to make big changes mid-cycle.  The latest version of OS X, OS X 10.7 "Lion", launched back in July.

Describes Gus Mueller founder of Flying Meat Software, a Mac software company, in an interview with MacWorld, "It’s being introduced in the middle of an OS cycle.  I could see Apple turning it on with the release of 10.8, but forcing the sandbox on developers with a 10.7.x update? That’s crazy."

The changes have some developers considering rebellion -- abandoning the Mac App Store.  Even Mr. Mueller a firm App Store proponent acknowledges that the changes "force me to remove one of my applications", the screenshot app FlySketch.

That's troubling because the Mac App Store has already had some struggles to succeed, in the face of problems like piracy.  Still, it's important not to overstate the reaction -- most developers who use the App Store would be unwilling to turn their back on this lucrative means of mass distribution unless they had.

In the end sandboxing should beef up Mac security, although limiting the kinds of apps that can run on Macs in some cases.  Developers may enjoy several unhappy months thanks to the decision, but they will likely adapt.  After all, iOS -- Apple's operating system for the iPad, iPhone, and iPod Touch -- already implements strict mandatory sandboxing for all apps.

Source: MacWorld

Comments     Threshold

This article is over a month old, voting and posting comments is disabled

By ltcommanderdata on 11/4/2011 11:12:41 AM , Rating: -1

Overall, Miller said, with Lion, Apple has raised its security game to the point where OS X is no longer the 98-pound weakling on the beach.

"It's always been the easiest to exploit and now it's to the point that it's not that easy anymore," he said. "OS X has always been way behind on security, but now it's more or less comparable [to Windows]. Once you have ASLR and DEP and some sandboxing, that's all anyone has."

This ties in with your previous article on the Deveil Robber Trojan where you claimed that OS X has weaker security than Windows 7 and linked to an old comment by Charlie Miller about Snow Leopard. You should be happy to note that with Lion having full ASLR, DEP, and App Sandboxing as you talk about in this article, Charlie Miller now believes Apple has made OS X as secure as Windows 7. Maybe comments about an over reliance on security through obscurity will stop now, because both Apple and Microsoft have made full use of the security tools at their disposal to harden the OS. It's really up to the user and user education now, which seems to be where the push for App Stores in Lion and soon Windows 8 is coming from.

RE: Sandboxing, Security, Lion, and Charlie Miller
By Iaiken on 11/4/2011 12:07:54 PM , Rating: 5
The browser, mail client, iTunes and plugins are not yet sandboxed as of this change, which is the channel that 100% of the current trojans and viruses exploit. If you bar all the windows but have no door on the main entrance then is your house really more secure?

Apple's half-assed implementation of ASLR and DEP are so notoriously bad that people have been easily working around them since 2009. Additionally, heaps are not yet randomized either so once you inevitably locate one, executing data from it is a simple matter. This has also led to the rise of several OS X botnets that are still growing and even several OS X exploit creation kits that allow you to build your own.

In most exploits, the only purpose of the Javascript portion is to get commands into the dyld so that they can be executed via shell script. In almost all cases, this can be done without prompting the user. The only real restriction is that you are limited to a 48MB memory space, which is still adequate so long as you keep your ROP payloads small, if you can't figure out how to stream files in segments by now, you probably shouldn't be writing code in the first place.

The only thing they have really done right was make it so that only ROOT could intercept keyboard and mouse inputs and pass them up to the Sandbox. This theoretically makes sandboxed apps immune to key logging, but only as long as each app runs in it's own sandbox. If a joint sandbox approach is taken, a keylogger within the sandbox would be able to dump it's captures to safe files that an external trojan can then send back home.

"Game reviewers fought each other to write the most glowing coverage possible for the powerhouse Sony, MS systems. Reviewers flipped coins to see who would review the Nintendo Wii. The losers got stuck with the job." -- Andy Marken

Most Popular ArticlesAre you ready for this ? HyperDrive Aircraft
September 24, 2016, 9:29 AM
Leaked – Samsung S8 is a Dream and a Dream 2
September 25, 2016, 8:00 AM
Yahoo Hacked - Change Your Passwords and Security Info ASAP!
September 23, 2016, 5:45 AM
A is for Apples
September 23, 2016, 5:32 AM
Walmart may get "Robot Shopping Carts?"
September 17, 2016, 6:01 AM

Copyright 2016 DailyTech LLC. - RSS Feed | Advertise | About Us | Ethics | FAQ | Terms, Conditions & Privacy Information | Kristopher Kubicki