Inside Sandboxing: how Apple plans to make the Mac App Store as secure as iOS

Posted:
in Mac Software edited January 2014


Apple is approaching its deadline for requiring that all apps sold in the Mac App Store be sandboxed for security, a policy that is drawing complaints from certain developers.



After the Mac App Store appeared in January 2010, Apple first indicated that sandboxing would become mandatory for all apps sold in the store by November. At the point, the deadline was shifted again until the beginning of March, in part because of complaints from developers and in part because of issues with the sandboxing mechanism itself.



Apple's mobile iOS platform has used sandboxing from the beginning, preventing the spread of viruses, malware and other serious security issues that have plagued other mobile devices ranging from Symbian to Palm OS to Android.



Sandboxing for Security



Apple initially began adding security sandbox features in Mac OS X Leopard. A sandbox provides an app with operating system controls that limit what it can do. The main security purpose of a sandbox is to prevent an app from doing anything it has no need to actually do, so that were it ever to be take over by malware, it simply couldn't do anything bad (within the foreseeable).



Apple has included sandbox support in some of its own apps bundled in Mac OS X, including Safari Web Content (something that helps reduce the damage caused by the Adobe Flash plugin when it fails or is compromised).



Preview and TextEdit also operate within a sandbox, with Preview isolating its PDF rendering in a secondary sandbox to negate any exploits hiding within PDFs. QuickTime sandboxes its video decoders, spinning off the task to processes named VTDecoderXPCService.










When Mac OS X Lion appeared, the system's sandbox support had grown sophisticated enough to be used by many common third party apps. Apple first anticipated that all apps sold in the Mac App Store would be sandboxed, but then gave developers a reprieve through November to study certain cases where this might cause more problems than it solved. The deadlined was then moved to March 1, just weeks from now.



Permissions for apps, just like users



Sandboxing works hand in hand with app signatures, serving as an app-centric security model with similarities to the users-centric file system model. When a user signs into a computer, he has account restrictions that might prevent him from deleting certain system files, for example. However, there's no finer grained control that can allow him to listen for network activity using a trusted app while blocking that same ability in a test app that he knows has no business to be accessing the network.



Sandboxes do for apps what file permissions does to files: they only allow access to certain features that have been designated in advance. Sandbox permissions are called "entitlements" (but share little in common with Android permissions model). There are over two dozen entitlements for app sandboxes in Mac OS X Lion, which range from the ability to read local files, to listening for network connections, to accessing the FaceTime camera to take pictures.



Because there's no way for the operating system to decide on its own what an app "should" or "shouldn't" be doing, developers must create apps that outline what they are designed to do, applying for entitlements that allow them to only do those specific, limited tasks.



Damage containment



By hardcoding an app's abilities to fit within an enforced set of entitlements, apps become safer because a flaw in the app that attempts do to something it has not been given permission to do (such as writing over your personal documents) is simply prevented by the sandbox rules. The same protections also prevent an app that might be infected with a virus or other malware from causing damage it was never expressly given the potential to ever cause.



Apple's sandbox technology is based upon the idea of being easy to use, rather than throwing lots of complexity at the user to figure out. So, rather than asking the user to interpret complex security policies, Apple watches for user intent and complies with what the user is doing.



When a user attempts to open a file or drags a file into an app, Mac OS X assumes the user is signaling an intent it should allow. Apple has built a mechanism for Mac OS X called Powerbox that enables sandboxed apps to open or save files at the user's direction, rather than trusting every app itself with full control of the file system.



Sandboxing can also serve as a way to split up a process into a series of tasks, allowing a heavy lifting component to be tightly secured in a separate sandbox with no connection to outside files or network access, greatly reducing any opportunities for finding vulnerable ways to attack the task, spread to infiltrate the entire program, and then subsequently take over the whole system.



Introducing this new structure and perimeters of security take more work, but it results in software that can better withstand crashes or even intentional attacks by malicious hackers, without suffering damage or at the very least, greatly limiting what the attacker can access.



Deadline approaching



While Apple has sought to avoid excessive work by developers, it wants Mac software to rapidly adopt these security features, and will soon (by the beginning of March) add sandboxing to the other minimum requirements of developers who want to sell software through the Mac App Store.



Apple has yet to bring sandboxing to its own iLife and iWorks apps, having focused initially on sandboxing apps and processes that run plugins or access codecs, such as Safari, Quick Look, QuickTime and Preview. That should change rapidly next month once the company's self imposed sandboxing deadline kicks in.



Apple similarly rolled out incremental enhancements its own bundled apps and separately sold app suites to incorporate support for 64-bit, starting with apps that benefitted most from the architectural shift.



[ View article on AppleInsider ]

«13

Comments

  • Reply 1 of 57
    I was waiting for the story to throw in something about the "iPad 3 with high resolution 2048x1536 display" and was pleasantly surprised.



    So how long before the "sandboxing is killing everything" comments that can be thrown to the wayside by using iOS as proof of otherwise?
  • Reply 2 of 57
    2oh12oh1 Posts: 503member
    The Mac App Store opened in January 2011, not 2010.



    It'll be interesting to see how many apps leave the App Store when they fail to comply or simply choose not to. I've already seen a few leave... but the incentive for being in the store is so great that I doubt it'll be a problem in the long run. Still... it'll be interesting to see.
  • Reply 3 of 57
    hmurchisonhmurchison Posts: 12,419member
    I'm most interested in seeing Apple's strategy for handling issues where Sandboxing prevents the useful addition of features.



    There's always a more secure way of doing things and if Apple's engineers are as smart as I think they are they will find a better remedy.
  • Reply 4 of 57
    asciiascii Posts: 5,936member
    "VTDecoderXPCService" - what a mouthful. I hope they don't push back the deadline again, I really don't understand the issue in apps specifying the access they want and why. I would understand if it was some fine-grained, onerous list of permissions they had to wade through, but it's not, it's just a few high level switches.
  • Reply 5 of 57
    wizard69wizard69 Posts: 13,377member
    I'm sure there are a few good programs that can't meet the requirements. That is not a problem as long as external installs are supported. Simply put I want to know that Mac App Store apps maintain a certain level of safety.



    Personally I don't think we are talking a lot of apps anyways. There will be loud complainers, however I suspect the count will be low.



    Quote:
    Originally Posted by 2oh1 View Post


    The Mac App Store opened in January 2011, not 2010.



    It'll be interesting to see how many apps leave the App Store when they fail to comply or simply choose not to. I've already seen a few leave... but the incentive for being in the store is so great that I doubt it'll be a problem in the long run. Still... it'll be interesting to see.



  • Reply 6 of 57
    agaaga Posts: 42member
    Look at the track record.



    iOS apps 'sandbox' as expected? no

    quality of apps gone up? no

    better choice of apps? no

    everything work the way you want? out of the box? no and no



    apple has great track record capturing money, but fail in the actual products backing up marketing hype. hope there is a place to go when you want to jump ship.
  • Reply 7 of 57
    gatorguygatorguy Posts: 24,176member
    Quote:
    Originally Posted by AppleInsider View Post


    Apple's mobile iOS platform has used sandboxing from the beginning, preventing the spread of viruses, malware and other serious security issues that have plagued other mobile devices ranging from Symbian to Palm OS to Android.



    If the inference is that Android doesn't use sandboxing, you would be incorrect. It too has "used sandboxing from the beginning", as does Chrome.



    http://developer.android.com/guide/t.../security.html
  • Reply 8 of 57
    Quote:
    Originally Posted by ascii View Post


    ...I really don't understand the issue in apps specifying the access they want and why. I would understand if it was some fine-grained, onerous list of permissions they had to wade through, but it's not, it's just a few high level switches.



    I think you said it best when you said you "really don't understand" or you would not have made such a sweeping statement.



    I think if you were more familiar with the all the models involved you wouldn't so that it is so easy.



    Take the case where you want to install a faceless menubar applet. Without the sandbox you can do this in a scripting language -- lets say a plain shell script and then put it in a pkg along with a tool that runs some engine that you or someone else supplies that run from the command line (via the terminal) i.e., a Unix application. Your script then calls this tool to do the real work. So now you have something you want to run that you may not have control over. This is one example that doesn't fit in your simple little world. There are others.



    BTW: This sort of thing already caused problems for some stuff that ran as I described -- Apple required that this be all rolled into one "real" application before it be sold through the Mac App Store.
  • Reply 9 of 57
    Quote:
    Originally Posted by Gatorguy View Post


    If the inference is that Android doesn't use sandboxing, you would be incorrect. It too has "used sandboxing from the beginning", as does Chrome.



    http://developer.android.com/guide/t.../security.html



    I believe what was being said was that the two concepts are different. Java uses a sandbox for everything (in theory). Since Android is written in Java it uses that model. The Mac OS X is a GUI running on top of BSD Unix and Apple's extensions to that create these sand boxes. They are similar in what they try to accomplish but go about it in different ways.
  • Reply 10 of 57
    Quote:
    Originally Posted by aga View Post


    ...apple has great track record capturing money, but fail in the actual products backing up marketing hype. hope there is a place to go when you want to jump ship.



    Well, you can always go to Android or WebOS or Chrome OS -- they have all done incredibly well at living up to what the have promised in their marketing hype.



    LMAO!
  • Reply 11 of 57
    One more good reason to avoid the app store. Adding sandbox support to an app costs time and money in development and testing, in addition to boxing in capabilities. Pay more for apps that do less? No, thanks. The threat that sandboxing 'solves' is non-existant anyway. Looking down the road, Apple will eventually have app approvals like on the iPhone/iPad.
  • Reply 12 of 57
    Dilger fails to address why many developers (and their customers) are unhappy about the restrictions. The article makes it appear that developers are upset only because the new restrictions mean more work for them, and not because it destroys the key functionality of the app.



    Unfortunately, every time I see the byline, I know the story will be very one-sided.
  • Reply 13 of 57
    The article is listed as a "Feature" and in the very first line says "a policy that is drawing complaints from certain developers". Great, here comes a frank analysis of those concerns, whether they're valid, or FUD; and a conclusion about whether the result in the end will be good for existing Mac users.



    I was to be disappointed. Where is the coverage of those concerns?



    Having access to the internet and some developer-only resources both of which AI must surely have, I can say they are many and varied.



    An example for the non-developer. Would the average user expect an application like Safari to be able to display a HTML file loaded from the local disc? Surely yes; you get an Open Dialog, select the HTML file, and voila! Yet it is claimed that this will not be reasonably possible under the App Sandbox!!! Is that a valid concern or FUD?



    Why is it claimed this fails? Well an application in the sandbox apparently only gets access to those files a user selects in an open dialog - the user in this example selects the HTML file, but they don't select any CSS styles sheets, images etc. the HTML file refers to, so the application cannot access them and has no straightforward and user friendly way to do so. Bizarre or FUD?



    The above is a simple case of what might be termed the included or associated file problem. It has been pointed out that Keynote can contain references to resources it displays on slides, so that would fail under the sandbox. Want to share some large videos between presentations, sorry you must make multiple copies to fit the sandbox. True or FUD?



    The article sadly reads as a PR piece from Apple after that first line, so of course it's great! Maybe it is really great and those developers of top-selling apps expecting to leave the App Store or severely reduce the functionality of their apps are just spreading FUD.



    AI, could you not at least include some of the concerns you referred to and allowed the reader to make their own mind up on whether it is FUD?
  • Reply 14 of 57
    hmurchisonhmurchison Posts: 12,419member
    Quote:
    Originally Posted by davida View Post


    One more good reason to avoid the app store. Adding sandbox support to an app costs time and money in development and testing, in addition to boxing in capabilities. Pay more for apps that do less? No, thanks. The threat that sandboxing 'solves' is non-existant anyway. Looking down the road, Apple will eventually have app approvals like on the iPhone/iPad.



    If I avoid the Mac App Store it means I lose the ability to sync content via my Mac apps to my iOS devices via iCloud.



    Sandboxing is really only going to affect a small subset of my apps...a few utilities like Keyboard Maestro, Moom and perhaps some transfer programs that I can purchase outside of the store.



    For the rest of the 80% of apps Sandboxing is more code for developers but more security in the end. iOS has far less malware than Android and I expect Mac OS X to have far less than Windows.
  • Reply 15 of 57
    asciiascii Posts: 5,936member
    Quote:
    Originally Posted by Damn_Its_Hot View Post


    Take the case where you want to install a faceless menubar applet. Without the sandbox you can do this in a scripting language -- lets say a plain shell script and then put it in a pkg along with a tool that runs some engine that you or someone else supplies that run from the command line (via the terminal) i.e., a Unix application. Your script then calls this tool to do the real work. So now you have something you want to run that you may not have control over. This is one example that doesn't fit in your simple little world. There are others.



    Doesn't it say something that your example is something so obscure? (faceless menu bar applet)



    Making apps by scripting command line tools together is the Unix way of doing things. It is great for prototyping/ad-hoc apps, e.g. a quick program to explore an idea, such as in an education institution or research lab where this OS was invented. But the Mac (even though it is now based on Unix) has the same monolithic app tradition that Microsoft has, and if you try to break out of that of course you will encounter difficulties. I think that by working in this space you implicitly accept that model, so complaining that your shell script won't work any more is a bit incongruous.
  • Reply 16 of 57
    asciiascii Posts: 5,936member
    Quote:
    Originally Posted by cdale View Post


    An example for the non-developer. Would the average user expect an application like Safari to be able to display a HTML file loaded from the local disc? Surely yes; you get an Open Dialog, select the HTML file, and voila! Yet it is claimed that this will not be reasonably possible under the App Sandbox!!! Is that a valid concern or FUD?



    Well where did they get that HTML from in the first place? If they saved it from Safari it will be a .webarchive, in which case all the sub-resources will be included in the bundle and will be accessible. If they got raw HTML from somewhere else, are they really the average user you are talking about?



    Quote:

    The above is a simple case of what might be termed the included or associated file problem. It has been pointed out that Keynote can contain references to resources it displays on slides, so that would fail under the sandbox. Want to share some large videos between presentations, sorry you must make multiple copies to fit the sandbox. True or FUD?



    Well that one is definitely FUD, because an app can ask for permission to access a user's media libraries (music, pictures, movies). So provided the user is keeping their stuff in the standard places in their home dir, they will be fine. If they are keeping them in non-standard places, well they are bringing it upon themselves.
  • Reply 17 of 57
    Quote:
    Originally Posted by hmurchison View Post


    Sandboxing is really only going to affect a small subset of my apps...a few utilities like Keyboard Maestro, Moom and perhaps some transfer programs that I can purchase outside of the store.



    For the rest of the 80% of apps Sandboxing is more code for developers but more security in the end. iOS has far less malware than Android and I expect Mac OS X to have far less than Windows.



    Does not iOS have less malware as it is a closed garden and every app has to come from a registered developer (requires some sort of proof of identity etc.) and is reviewed by Apple prior to going in the store?



    The same is of course true for the Mac App Store, so what does sandboxing really gain you the user? Unless of course you think Apple is going to make 10.8 only run sandboxed apps (and you believe sandboxing will improve security, probably not a trivial given)? If so then bye-bye to that 20% of apps you'll be purchasing out of the store...



    Indeed that is surely a valid question: Does sandboxing actually makes any sense unless Apple is planning a sandboxed-only restriction for 10.8? It avoids any need for a walled garden... (there are somethings no sandboxed app can do regardless of entitlements - scripting for one - leaving such features to Apple-only apps to provide). Food for thought.
  • Reply 18 of 57
    Quote:
    Originally Posted by ascii View Post


    Well where did they get that HTML from in the first place? If they saved it from Safari it will be a .webarchive, in which case all the sub-resources will be included in the bundle and will be accessible. If they got raw HTML from somewhere else, are they really the average user you are talking about?



    Well some "average" users do actually edit HTML, but you miss the point - it is an example of a kind of whole class of applications.



    Quote:

    Well that one is definitely FUD, because an app can ask for permission to access a user's media libraries (music, pictures, movies). So provided the user is keeping their stuff in the standard places in their home dir, they will be fine. If they are keeping them in non-standard places, well they are bringing it upon themselves.



    So when a group of people are working on a collection of presentations and they pass copies of those presentations and common resources between themselves (by USB stick, network share, etc.) they are "bringing it upon themselves" for not immediately installing those common resources into each user's media libraries? Fine if you really think that, I wonder whether they will. FUD?



    BTW iTunes supports not copying music into the media libraries... I wonder if anybody has used that feature to share music from a network volume? (Answer yes.) If iTunes is sandboxed will that be effected?



    Some more examples:



    - Ever received a compressed file in multiple parts? You need to give permission for each part somehow... (this might have an easy answer which doesn't apply to



    - Ever received some C (or other language) program code (think lots of students for a start, not just professional programmers). Such code often includes references to other files... What to analyze it for conformance to security standards - sorry the security sandbox makes that hard...



    - Then there are the industry standard file formats used in various fields which apparently fall foul of these restrictions...



    The question isn't whether these examples exist, they are very real. The question is whether it is FUD that removing them from the Mac (App Store), or modifying them to fit, will be a big impact on existing users? Currently we hear stories of big production houses abandoning Apple over the uncertainly generated by Final Cut X, is Apple lining up another "wait 2 years and you'll get all your apps back" scenario? Or is all the developers concern FUD?



    I'd hoped AI would at least cover this in a "feature" for more than half the first sentence.
  • Reply 19 of 57
    hmurchisonhmurchison Posts: 12,419member
    Quote:
    Originally Posted by cdale View Post


    Does not iOS have less malware as it is a closed garden and every app has to come from a registered developer (requires some sort of proof of identity etc.) and is reviewed by Apple prior to going in the store?



    The same is of course true for the Mac App Store, so what does sandboxing really gain you the user? Unless of course you think Apple is going to make 10.8 only run sandboxed apps (and you believe sandboxing will improve security, probably not a trivial given)? If so then bye-bye to that 20% of apps you'll be purchasing out of the store...



    Indeed that is surely a valid question: Does sandboxing actually makes any sense unless Apple is planning a sandboxed-only restriction for 10.8? It avoids any need for a walled garden... (there are somethings no sandboxed app can do regardless of entitlements - scripting for one - leaving such features to Apple-only apps to provide). Food for thought.



    Breaches can come from cracks external to the store and so Sandboxing is there as built in quarantine system should an attack come from outside the store.



    I'm interested in seeing if scripting can be fortified and thus have the ability to punch through sandboxes. We'll see what's in store. In the long term there has to be a secure way of letting apps communicate and even control other apps to a point.
  • Reply 20 of 57
    Quote:
    Originally Posted by hmurchison View Post


    Breaches can come from cracks external to the store and so Sandboxing is there as built in quarantine system should an attack come from outside the store.



    Let's see: applications are digitally signed, surely any frameworks they use are (or can be) digitally signed. Will iOS even run an application which fails signature verification (or should it)?



    There is an article somewhere on the web which makes this argument - sign everything (and as every developer is registered you can easily give them a unique signing certificate) and either refuse to execute non-signed code or at user option allow it (so, say, students can write and execute their own code). If you do that on top of the existing registration/review you've sown the system up as tight as the App Sandbox does but without removing features. Is this valid?



    Some have probably realised I'm playing the devil's advocate on this thread with all these examples - but the article led with promise and singularly failed to fulfill. It is a debate that needs to be had, not blind acceptance that somehow Apple will figure it out without detriment to existing customers (and developers). Yet Apple don't have a good recent track record in this area [Final Cut X, Rosetta, the Rosetta killing "security update", maybe even the Lion update (which was really a sandbox update, not that that was advertised widely) that caused every app to crash for some...) - there seems to a bit of "losing the plot" about all this, oops back into devil's advocate mode! ;-)]



    My point is simply, AI could and should have done better - or simply reported "it is coming". A puff piece with a half-line nod to developer concerns surely doesn't meet the bar of "feature". Maybe I expect too much...
Sign In or Register to comment.