backtop


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

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.


"Let's face it, we're not changing the world. We're building a product that helps people buy more crap - and watch porn." -- Seagate CEO Bill Watkins














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