Sandboxing divides Mac App Store developers

Sandboxing divides Mac App Store developers

Summary: While some developers are spooked by sandboxing, some don't think that sandboxing is necessarily a bad thing. Developers will have to do more work, but it will increase security as a result.

SHARE:

Apple told Mac OS developers that all applications submitted to Apple’s Mac App Store must implement sandboxing by March 1, 2012.

mac_app_sandbox_ogrady.png

Sandboxing is akin to what Apple enforces in iOS. Developers are only allowed to use a prescribed set of APIs that exist in a sandbox, and there's no data permanence nor the ability to access resources or data outside of that sandbox. The advantage is security and stability (there's no way for a malicious app to delete your home folder, for example) but the disadvantage is limited application functionality (a sandboxed app can't directly access to any files or frameworks on the system, nor can it access the network or any devices.)

Ars Technica's John Siracusa described sandboxing in his epic Lion review:

Running an application inside a sandbox is meant to minimize the damage that could be caused if that application is compromised by a piece of malware. A sandboxed application voluntarily surrenders the ability to do many things that a normal process run by the same user could do. For example, a normal application run by a user has the ability to delete every single file owned by that user. Obviously, a well-behaved application will not do this. But if an application becomes compromised, it may be coerced into doing something destructive.

[Ars also published a deeper dive on Mac OS X's particular implementation of sandboxing, which is worth a read.]

Pauli Ojala, developer of Conduit, a realtime video and graphics compositing tool is afraid of what could happen if Apple disallowed independent software distribution and required developers to distribute their Mac OS X applications exclusively via the Mac App Store.

Since the Mac isn’t a phone, most apps need to do something more persistent than e.g. rendering a nice image of a collapsing sand castle. To enable these apps to perform their job, Apple has created a list of permitted capabilities called “entitlements”

Apple hasn't indicated that it plans to do this, but what if it did?

Ojala feels "slightly queasy" about a future as described in this 3-year old blog post by Tim Bray:

I don’t want to write code for a platform where there’s someone else who gets to decide whether I get to play and what I’m allowed to sell, and who can flip my you’re-out-of-business-switch any time it furthers their business goals.

While some developers are spooked by sandboxing, some don't think that sandboxing is necessarily a bad thing. Developers will have to do more work to request entitlements, but it will increase security for App Store users as a result.

Will Shipley, developer of Delicious Monster, is clearly in the pro-sandboxing camp, blogging recently that "the Mac needs to be as secure as the iPhone." Shiply goes on to say that although Apple has the tools, "they are forcing developers to use the wrong ones."

There are three primary ways Apple increases security of applications running on the Mac and the iPhone: Sandboxing, Code Auditing, and Certification. While all these are incrementally valuable, none is perfect on its own.

The problem Mac developers are facing is that the two that Apple is enforcing on the Mac App Store (Sandboxing and Code Auditing) are implemented currently to be actively bad for developers and not particularly good for users. And the method that would provide the most benefit for developers and users (Certification) isn’t enforced broadly enough to be useful.

Where do you fall on the Sandboxing issue? Is it evil incarnate or high-security Windows differentiator?

Chart: Pauli Ojala

Topics: Apps, Apple, Hardware, Software Development

Kick off your day with ZDNet's daily email newsletter. It's the freshest tech news and opinion, served hot. Get it.

Talkback

12 comments
Log in or register to join the discussion
  • RE: Sandboxing divides Mac App Store developers

    It is also frustrating for the end user.

    You use a feature that has been on a app for three years and you think your doing yourself a favour by upgrading only to find that feature is gone because of sandboxing. Not what I call user friendly.
    aroxnicadi
  • Why not a risk-based approach for app sandboxing?

    I think that Apple is getting carried away by requiring sandboxing for all apps in the Mac App Store. The OS X market share on the desktop is still relatively small, approximately 6%, and is growing slowly. In addition, OS X malware, while it does exist, is not exactly common. But, which applications to sandbox?<br><br>Sandbox only those apps which pose the greatest risk for the user base:<br><br>1. apps that are internet-based (e.g., web browsers, email clients, IM clients, media players)<br><br>2. apps commonly used to open documents obtained via the internet (e.g., office suites, standalone word-processors, PDF viewers, image viewers)<br><br>3. apps in 1. and 2. that are used by a large percentage of the consumer, SOHO and small business Mac OS X user base (e.g., a threshold of 10%) ~ Note: this is an app popularity measure<br><br>4. apps in 1. and 2. that are used by Apple's OS X enterprise clients ~ Note: this is an acknowledgment that enterprises are targeted with attacks<br><br>Does this make some sense for Microsoft's Office for Mac? Yes. How about AutoDesk's AutoCAD? Not so much.<br><br>And once the higher-risk apps have been sandboxed, monitor the user base and remaining apps to see if further app sandboxing makes sense. And also monitor the apps that have been sandboxed as the default profiles may be too restrictive for some users (and, perhaps, not restrictive enough for malware miscreants). Apple may want to consider offering multiple profiles for sandboxed apps in their Mac App Store, where users can download a profile better suited to their app usage (e.g., see OpenSuSE's AppArmor profles at <a href="http://apparmor.opensuse.org/" target="_blank" rel="nofollow">http://apparmor.opensuse.org/</a>). In any case, OS X users should be provided with an option to disable app sandboxing if it interferes with how they use an app (I'm assuming that modifying an app's profile will be beyond the capability of most of their users).
    Rabid Howler Monkey
    • RE: Sandboxing divides Mac App Store developers

      @Rabid Howler Monkey
      Pulling of resources (which could be compromised) from the network is in the Cocoa APIs.

      By making this a requirement of apps distributed through the app store means the pain will be less than what the Windows users went through when Microsoft got serious about applications that grabbed administrative privileges.

      Oh yes, sandboxing will be coming to Windows. It will start with contracts.
      DannyO_0x98
    • AutoCAD has scripting support and it had its own viruses, so it ...

      @Rabid Howler Monkey: ... needs sandboxing.

      If you look at more than half million iOS applications, you will see that there is [b]nothing that is really limiting under sandboxing[/b]. Even large and complex projects like Unreal 3 graphics engine games are fine.
      dderss
      • RE: AutoCAD has scripting support and it had its own viruses, so it ...

        @dderss The viruses of which you speak (1) were very VERY few, and (2) were Windows viruses. And AutoDesk did not sandbox AutoCAD on Windows Vista/7 as did Microsoft with Internet Explorer protected mode and Office protected view, Google with their Chrome web browser and Adobe with their Reader X.

        Of these companies, Google is the only one that took advantage of OS X sandbox hooks (e.g., the 'sandbox_exec' command, *.sb files) to sandbox the Chrome web browser. Why? Because web browsers with JavaScript, IFrames, Java, Flash and image loading enabled by default are dangerous. Sorry, but AutoCAD is not dangerous. Not even on Windows.

        Applying sandboxing to all Mac OS X apps, rather than using a risk-based approach, is an overreaction IMO. And iOS is a bad example as sandboxing was present from the beginning. Users did not know anything else so they adapted. This is not the case for Mac OS X and I believe that Apple will see users requesting the capability to modify app profiles (read *.sb files). Alternate app profiles will either be provided by Apple via the Mac App Store or users will go outside of Apple to obtain app profiles that are more in line with their workflows. The AppArmor profile repository at OpenSuSE makes it clear that all users do not share the same workflow for apps.
        Rabid Howler Monkey
  • RE: Sandboxing divides Mac App Store developers

    It just seems Apple considers the application model available on Windows Phone is more secure and decided to adopt the same strategy.
    Nothing more to analyze here. This is a proactive move in order to stop/avoid malware propagation that has started to plague Android.
    TheCyberKnight
  • You can't worry about that

    <ul><i>who can flip my you???re-out-of-business-switch any time it furthers their business goals.</i></ul><p>Truth is, that happens to anybody who gets on the shelf at WalMart, Sams, Best Buy, or Costco. Before you know it, those guys are 90% of your business. Odds are if even one of them booted you off the shelf, you'd croak.
    Robert Hahn
  • RE: Sandboxing divides Mac App Store developers

    This is ineveitable. The internet is the wild wild west and if we can't get serious about malware on the internet we have to lock down our systems.
    jatbains
    • RE: Sandboxing divides Mac App Store developers

      @jatbains

      yes the wild west is dangerous.

      I am not sure that all applications should be sandboxed, I need to rethink how some sort of multi-app workflow will function if the data is not accessible by all apps.

      Certainly Apple is providing new ways of thinking about user experience that are suprisingly working out, even though us programmers are somewhat confused at times.

      Final Cut X is interesting in this respect.

      I have seen a lot of existing Final Cut Pro users screaming about the workflow not being what they are used to.

      At the same time I have a colleague that really has never quite understood the Final Cut workflow, and in the process of helping him I have realised that the Final Cut Pro workflow is just not sensible in many cases. Strangely the Final Cut X workflow and file management is what he thinks Final Cut Pro is.

      So many people talk about a file being in 'Word' and expect Word to contain the file. Yes these are the computer illiterate people.

      In iOS this is literally true, due to sandboxing. A Pages document is in the Pages app.

      Final Cut Pro X somewhat follows this model of the files being in the App, not so much on a Drive, and referenced in a Project.

      Being someone who never thinks of a file being in an application, this seems a little limiting to me, but maybe I need to re-think.

      Or maybe the computer should give in to the user's thinking on this???

      Or maybe we just are yet to realise the best way to use a computer?

      I can certainly see reasons to not work in terms of disks and folders, especially in the days of cloud computing. Not that I am a fan of cloud computing.

      So is Apple right on this issue? Definitely makes sense for some apps - but is a complete sandboxed future the way to go? I am not sure yet.

      Time we all do some thinking and learning.
      richardw66
  • Sounds like a good idea to me...

    No... Not all apps "need" to be sandboxed, but they should be if you take security seriously...

    Is there any app that can't function in a sandbox? No...

    So why limit sandboxing to only a few apps. If they did that, then it would just a matter of time before someone comes along and figures out a way to exploit the non-sandboxed apps. By requiring that everything run in the sb, then you make it that much harder to exploit anything. It's a little more difficult for the developers and Apple, but it's a win/win/win for Apple, Developers, and most importantly, consumers... Apple wins via increased security. Devs win by not having their apps compromised, and consumers win by not being exploited. And it makes it really easy to spot anyone trying to slip a bad app into the app store. The scum bag bad guys will focus on easier targets.
    i8thecat4
  • A lot of questions...

    I'm not enough of a techie to fully understand all the implications here, but I'm a bit concerned, especially if Apple starts at some point to require that all Mac apps must go through the app store.

    I realize that the list of "entitlements" will most likely expand or change, but when I see a sentence like this: "nor can it access the network or any devices", what will that mean down the road? I'm the lone Mac in a small business (architecture) that accesses all my files on a Windows network. Any work-related files need to reside on the server where they can be accessed by everyone and are arranged in directories organized by projects. I can't have files residing in sandboxes on my machine.

    So will the ability to organize files in a way that makes sense to me be gone? What if I need to send a client a .jpg file, a .pdf file, a .doc file and an AutoCAD file? Do I really need to send four separate emails from each of the four apps involved? That's craziness. Also, there are file name repetitions from project to project. Even if I were a one man business with one Mac, I would have to have huge file names to keep files unique in the absence of a folder hierachy. For example, I'm sure there are hundreds of "floorplan.dwg" files on our server. Am I supposed to name a file "projectnameX preliminary rejectedversion floorplan.dwg" to keep it apart from "projectnameY final floorplan.dwg"?

    As someone else mentioned, what about multi-app workflows that many of us pros use? I have company charts created and edited in Illustrator but saved as .pdf files so that no one else needs a copy of Illustrator just to open them and so that I'm the one controlling the changes. Or, I'll take an AutoCAD floor plan, import the .dwg file into Illustrator to tweak line weights and make other adjustments, export the file to .psd where I use Photoshop to create an artistic color rendering, and finally save it as a .jpg for the client or for presentations in PowerPoint.

    What if I create a design sketch in SketchBook Pro and Save As to .psd? Where's the file? With the app that created it or with the app whose file format I've saved it to?

    How does all this fit into the sandboxed future? Am I going to be forced back to Windows? Can someone put my mind at ease?
    weels
  • Necessary overkill?

    First, I'm amused that several people think Apple's going too far by ordering sandboxing of MacOS X apps, especially since so many folks (mainly Android/Linux and Windows folks) often criticize Apple for being too lax about security. Damned if you don't, damned if you do, I guess. ;-)

    That said, I'm all for security, but I don't really see the proposed method of "sandboxing" as being particularly effective.

    First, Mac apps don't need to be installed through the App Store, as with iOS -- folks can just download any old app. And I think that's a good thing -- freedom of choice and all that -- despite the potential downside. But since apps can come in from "anywhere", those non-approved apps can do things any which way they like and potentially nuke your system, even if the Mac App Store apps can't.

    Which brings me to point #2: this is done on the honor system (though enforced by Apple for apps going through the App Store). Anyone remember the old Mac OS days when it was up to app developers to code their apps to play nice with other apps, since the app (not the OS) had full control of the processor and direct access to hardware when it was the active app? Despite good intentions, things didn't always work out well. And some folks just didn't know how to play nice. And there are those that don't want to ... or at least won't bother.

    Third, this will inevitably lead to painful changes for end users in how they use their systems. At the very least, they'll have to relearn how to use their systems. Or they may find that certain things will no longer be possible. Without access to files outside the app, how would one open a PDF in Preview, for instance, if it's ID'd as an Adobe Reader doc? Or how about opening a random JPG image into PhotoShop if you can't go into PhotoShop, choose "Open..." and browse to the file that's stored in some other app? This will cause huge workflow headaches that people wrestle with in iOS when they start to try to push the boundaries by trying to replace their desktop/laptop with, say, an iPad. The iOS "files in the app" model works partly because those devices have some practical limitations (in part because of these sorts of issues, but also because of screen size, input devices, etc.). But the Mac OS does more and has more complex apps. And we have decades of history of doing things certain ways -- ways that people like working and which fit well with certain workflows.

    To me, it seems like Apple needs to spend a little more time thinking outside the box on this. They've done all these incredibly complex migrations in the past -- stuff no one had ever done before, like migrating from the 680x0 to the PPC without a hitch ... and then to Intel ... and from MacOS to Rhapsody to OSX ... and other stuff. They're smart people. They know how to make things seamless and effective. But the proposed approach doesn't seem like either.

    I'd love to "hear" others' thoughts on this. I'm sure I'm missing something, but to me, it seems like Apple needs to make the OS more restrictive and force developers to call upon it to open, save and execute files so that executable files can only be installed to and launched from certain directories, and so that data files are always written to directories from which nothing can ever be executed ... only read or saved. Separate the operational files from the data files and have the OS prevent the two from intermingling. Sorta like how cookies are only accessible by the server/domain that set them. And any non-Apple apps should be installed in such a way that they run in a more restricted manner -- limited calls or better validation or something -- that prevents them from doing things that they shouldn't be allowed to do, to prevent buffer overflows and whatnot. (I'm reminded -- of all things -- of NASCAR's change to its rules system a few years ago when it switched from specifying what's against the rules to specifying only what is allowed and clarifying that anything else is specifically disallowed. It's a sucky system for racing, but perhaps a good model for app security?)

    Apple might even be able to implement changes solely within the OS itself, eliminating any work for developers -- just change how the OS handles calls to open, save or execute files, and change installation processes to do more validation, better error trapping and be more restrictive. Then, if someone tries to write an app that would inappropriately access stored data other than its own or to gain escalated privileges, it wouldn't matter: the hardened OS could refuse the call or could at the very least present a warning dialog (or two) in an attempt to even head off social engineering attacks. Perhaps it could/should be couple with encryption so that only the OS can de-crypt files so that they can be read or executed? That way, even if an app somehow tricked the OS and gained access to data, it'd be virtually useless. (I can imagine scenarios that might complicate this -- data shared through a server with Windows or Linux boxes, for example ... that would have to be decrypted data ... and what about files coming from those machines? But again, those could be forcibly stored to restrictive directories ....?)

    So (and I'm asking this honestly) why wouldn't something like what I've described work? I must be missing something -- it just seems too easy.
    jscott69