Want to read Slashdot from your mobile device? Point it at m.slashdot.org and keep reading!


Forgot your password?
OS X Operating Systems Security Software Apple

Apple To Require Sandboxing For Mac App Store Apps 584

mario_grgic writes "And so it begins: Apple will require that all Mac apps submitted to the Mac App store stick to strict sandboxing requirements. This means you must ask Apple for read or read/write entitlements for additional folders outside your Application Support folder before your app is approved. There are also restrictions on direct hardware access, communication to processes your app did not start, or even something simple as taking a screenshot. All that is needed after this to turn your Mac into an appliance is to only allow app installations from App Store."
This discussion has been archived. No new comments can be posted.

Apple To Require Sandboxing For Mac App Store Apps

Comments Filter:
  • by onefriedrice ( 1171917 ) on Thursday November 03, 2011 @12:36PM (#37936398)

    You don't ask Apple for anything. You just declare what your application needs from OS to function.

    Ever heard of Android? Works the same way.

    But but but it's more fun to sensationalize the truth so we all can have another pretend reason to hate Apple.

  • by Ambitwistor ( 1041236 ) on Thursday November 03, 2011 @12:43PM (#37936534)

    This basically makes 3rd-party software - like you get from Fink, for example - non-existent, as far as a Mac user is concerned, because all software for Macs will have to be retrieved from this "app store".

    You're spreading FUD.

    Software for Macs will NOT have to be retrieved from the app store only. This does not kill 3rd-party software or Fink. This announcement ONLY applies to applications that are voluntarily listed in the app store by their developers. Developers do not have to use the app store to distribute their apps.

    It is possible that Apple may someday require all apps go through the app store, as you suggest, but that's not what this announcement is about.

  • by slim ( 1652 ) <john@hartnu p . net> on Thursday November 03, 2011 @12:46PM (#37936586) Homepage

    OK, not the "central authority can veto apps" part.

    But the "app package declares what system calls it needs to access; package manager reports it; sandbox enforces it" part.

    You can achieve it in a limited way with things like chroot, but having it conveniently bundled is nice.

    # apt-get install gnuTunes
    INFO: gnuTunes requires:
      - read/write access to ~/.gnuTunes/ for the user
      - access to audio output
      - read access to the optical drive
      - read/write access to ~/Music/ for the user
      - read access to /usr/share/Music/
      - make HTTP requests to http://gracenote.com/ [gracenote.com] ... and so on.

  • by tepples ( 727027 ) <{tepples} {at} {gmail.com}> on Thursday November 03, 2011 @12:49PM (#37936660) Homepage Journal

    Ever heard of Android? Works the same way.

    Every time Google adds a sensitive API to Android and documents it, it adds a corresponding permission to the application manifest schema. This means every single documented API in Android is either A. covered by the generic permission for all installed applications or B. covered by one of the permissions that an application can request. This Mac App Store sandbox, on the other hand, appears to add a category C: APIs that no sandboxed application can request, even with good reason. The page behind the second link [lacquer.fi] points out a few noticeable omissions in the available permissions. This points to one of two paths of speculation: either Apple will add permissions covering these holes in a later revision of the policy, or Apple plans to completely remove the functionality corresponding to those holes in future versions of Mac OS X.

  • by sribe ( 304414 ) on Thursday November 03, 2011 @01:05PM (#37936988)

    - The real news is that the deadline was announced today as March 1 2012, whereas back in the summer at WWDC it was announced as November 1 2011. So they've just delayed this for 4 months--probably to continue refining it.

    This means you must ask Apple for read or read/write entitlements for additional folders outside your Application Support folder...

    - But you are always allowed access to read/write files that the user selects through the normal open/save dialogs. So this restriction just applies to files you create without the user's specifying the location. Now, this still does potentially create some problems with some kinds of legitimate file access, keeping track of and using previously-saved/read files, and that sort of thing. But it's not nearly as drastic as the summary makes it sound.

  • by TheRaven64 ( 641858 ) on Thursday November 03, 2011 @01:10PM (#37937070) Journal

    You seem to misunderstand what the sandbox is. OS X has had a set of APIs for sandboxing applications since 10.5. The sandbox(7) man page will tell you a lot about it. This comes with a few default policies, and you can add more. If you download an app and don't trust it, then you can start it in a sandbox (there's no GUI for doing this, which sucks, but it would be a few hours work to add one).

    This isn't an 'authoritarian model' any more than the UNIX process model is: the kernel is the authority and any application has to go begging to it for access to anything. You can ship your own sandbox policies if you want to implement privilege separation and so on in your OS X application, and a lot of Apple's programs use it already, and have for a while - you may remember a mDNSResponder vulnerability that only affected 10.4, because it ran in a sandbox on 10.5. You can see the sandbox definition that mDNSResponder uses and it's pretty trivial to put something similar together for your own daemon.

    The only difference now is that Apple is defining a sandbox profile for normal applications and forcing developers to use it if they want their application in the App Store. It is not a whitelist of applications, it's just a default security policy that applications must work with. This is like Microsoft requiring applications to work as non-Administrator users for the Designed For... certification, or a Linux distribution rejecting suid root apps from the default repository.

  • by betterunixthanunix ( 980855 ) on Thursday November 03, 2011 @02:13PM (#37938076)

    "Idiot Ready" actually means 'thoughtfully designed'.

    No, it means "designed for people who know nothing and who are unwilling to learn." The history of the PC industry has shown everyone that despite the initial optimism of hackers like Lee Felsenstein, the majority of people are simply not interested in learning about their computers. Most people want to use their computers to be passive consumers of music and movies or to spread their intimate details on social networking sites, and they just get aggravated by the notion that they might have to learn more than the location of the power button in order to do so.

    To put it another way, Apple's current design methodology is centered around the notion that people should not have to think about how to use their computers. Let me emphasize the important part: people should not have to think. If the term "idiot" does not properly convey the notion of someone who is not willing or able to think, I am not really sure what would.

  • more nonsense (Score:4, Informative)

    by Tom ( 822 ) on Thursday November 03, 2011 @02:17PM (#37938138) Homepage Journal

    ok, it really is nonsense-summary week on /.

    This is fantastic news for everyone who is worried the slightest bit about security. This has absolutely nothing to do with turning a Mac into an appliance, and nobody from within Apple has ever alleged that non-App-Store installations would be made difficult or impossible.

    But what this is is a huge and desperately step needed in putting applications into their own corner. Imagine what would happen if random apps couldn't crap all over your system? The horror! Most of the spy- and malware would go away!

    The OS X sandbox is actually a fairly nifty beast, but is has been under-used. This is a great step into pushing it out and making developers accept that just because I want to use their app I don't mean to give them full access to everything on my system - not even everything I can access with my user account.

  • by Anonymous Coward on Thursday November 03, 2011 @02:40PM (#37938506)

    I dont have an iPhone, but with Android you have permissions, like entitlements. The application is written to 'ask' for these perms from the OS, but the *end user* gets to decide if they want to accept them or not - when they install the application. Not the case with IOS. The article says: "It’s important to note that these entitlements are granted by Apple, not by the user herself." It sounds like Apple has to approve your permission request, when it approves the application itself. That ridiculous! Im not trying to blindly hate Apple here, but that very clearly *sucks* compared to the more 'open' Android model, at least in my opinion. That kind of stuff stifles innovation! Everything on the iphone seems so locked up to me.. heck.. Didnt iphone OS 'like *just* get the ability to multitask, and the apps have to be explicitly written to support?! Co-operative multitasking OS in 2011!?! :)

Thus spake the master programmer: "Time for you to leave." -- Geoffrey James, "The Tao of Programming"