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

 



Forgot your password?
typodupeerror
×
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 elrous0 ( 869638 ) * on Thursday November 03, 2011 @12:21PM (#37936150)

    All that is needed after this to turn your Mac into an appliance is to only allow app installations from App Store.

    I've made the argument that this is exactly where Apple is headed for a long time now. I'll summarize the responses you're going to get:

    • They would never isolate developers like that.
    • They depend on the creative crowd that would never tolerate being locked down like that
    • Adobe and other developers would bitch about having to go through the app store and this would stop Apple from doing it
    • We'll probably still be able to find a way to jailbreak it, so that makes it okay
    • Just because they do it on iOS doesn't mean they'll ever do it on Mac's. They're COMPLETELY different things.
    • The app store is just for iOS, Apple would be stupid to put it on Mac's. [they don't use this one so much anymore]

    Of course, the second that Apple announces that they ARE, in fact, locking down the Mac's too, I suspect you'll see one of two responses (should be interesting to see how it goes):

    • It's a great idea! I can't wait to buy one!! [this would have been the guaranteed response if Steve hadn't stepped down]
    • Steve would have never done that!! [i.e., the faithful followers of Steve begin to denounce the new false messiah]
    • by dzfoo ( 772245 ) on Thursday November 03, 2011 @12:27PM (#37936226)

      You forgot a couple of answers:
      - Who the f*ck cares, as long as it works.
      - Why do you care, just don't use the Mac App Store, don't upgrade your OS to the version that locks you out, or don't use a Mac.

              -dZ.

      • or don't use a Mac.

        That depends on how successful Apple and Microsoft are at suing Android out of existence. If they succeed, mobile app development will pretty much require using a Mac.

        • Developing for WP7 requires a mac?

          • by tripleevenfall ( 1990004 ) on Thursday November 03, 2011 @12:44PM (#37936554)

            People are developing for WP7?

            • by Motard ( 1553251 )

              Yep.

            • Strictly, yes: I bet at least two people are hacking out fart apps as we speak.

            • Would develop* the death of android would not prompt an exodus to apple but to wp7, most people who own an android specifically chose not to go apple cause of apple bs, and while microsoft has their share, it's not nearly as bad.

              Then again the death of android is only speculative by people who are not even close to being qualified to make that judgement (slashdotters), so I'll be enjoying my android for a long time to come I'm sure.

              • by Sir_Sri ( 199544 )

                Lots of people who are slashdotters are the ones writing the software to be deployed in future. 2 years ago I had iPhone projects out the wazoo (before that it was Nokia/Qt and blackberry), last year it was blackberry because we're close to RIM and they gave us free stuff, along with iPhone and QT was gone, this year it's android, and next year we're slated for WP7.5 or WP8.

                Windows phone development is pretty easy, and I have a suspicion they can angle into the business market from RIM, while still tying i

          • No, developing for WP7 just requires having a killer app good enough to get iPhone users to pay the ETF on their current contract and switch to a WP7 phone. I haven't seen anything close to such a killer app yet; would you mind showing me?
    • by Stellian ( 673475 ) on Thursday November 03, 2011 @12:38PM (#37936432)

      There's nothing wrong with the sandboxing model per se. It's probably the only way to make our computers more secure. That Apple is moving in that direction should not be surprising: they make idiot-ready software (also known as good software), and you can't really have security and idiot friendliness without a trusted 3rd party to sort out the nitty-gritty details.

      It should also be unsurprising that Apple moves to an authoritarian model where it and it alone can act as the trusted 3rd party. Almost everything Apple does is to maximize clout and control over the product environment. Apple is a control freak: it's profitable and risky, it almost got them killed when the PC revolution happened.

      I would much rather like to see a sandbox where multiple private companies publish application profiles and the consumer choice is maximized; that's a nice role for the AV companies to play, move from a blacklist to a whitelist model. Should such a company turn into Big Brother, limit the consumer choice and push it's own interests, the consumers can easily move to a different "security provider".

      • by Tetsujin ( 103070 ) on Thursday November 03, 2011 @12:59PM (#37936882) Homepage Journal

        There's nothing wrong with the sandboxing model per se. It's probably the only way to make our computers more secure. That Apple is moving in that direction should not be surprising: they make idiot-ready software (also known as good software)

        I take exception to this.

        "idiot-ready" software is good software... for "idiots".

        (Of course, they're not really idiots, most of them - they're regular people who desire a simple level of interaction with their computer. But I'm just running with the "idiot-ready" terminology there.)

        That approach to software design is "one size fits most" - but it's not "one size fits all" because the limitations of a simple UI will inevitably interfere with (or at least fail to support) something that someone is trying to do. When your expectations and skills pass a certain threshold, a simple UI is not necessarily a good UI.

        • Excellent. I have never seen all this common sense about this matter summarized in a post so briefly without resorting to typical "fanboy-ish" claims.
          Someone should mod this up!

        • "idiot-ready" software is good software... for "idiots".

          No, it's not. That's a myth started to defend the quality of OSS software and perpetuated by people who think they're above the masses because they know how to turn on encryption on their WiFi router.

          "Idiot Ready" actually means 'thoughtfully designed'.

      • 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 dgatwood ( 11270 ) on Thursday November 03, 2011 @02:47PM (#37938626) Homepage Journal

          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.

          Well, it's more like a range of default security policies tailored to the application, but yes. Apple has created a series of multiple high-level sandbox profile options that your app can choose from, depending on what it needs to do. If you are selling your apps on the Mac App Store, Apple vets those options to ensure that they make sense based on what your application does. If you aren't selling your app on the Mac App Store, this does not affect you at all, though you are strongly encouraged to sandbox your app because doing so makes the platform more robust against viruses, etc. At that point, the onus is on you to make sure that the options you choose are sane.

          The big thing that makes the 10.7 App Sandbox different from the prior incarnations is the addition of PowerBox. By moving the open and save dialogs into a separate (system-provided) application that has the ability to add entitlements (capabilities) to your application's sandbox on the fly, it means that your app can access the files that the user specifies, and nothing else (outside of your app's personal scratch space). This is a significant win for security, as it puts the user directly in charge of what files an application can access.

          I could go on for a while about privilege separation and techniques for making your app more secure, but that's a bit out of scope for this discussion forum. Go read App Sandbox Design Guide [apple.com] if you want more details.

          Also, according to MacWorld, the original deadline was November (Source: MacWorld [macworld.com]). The news is that Apple pushed the deadline out by four months, not that Apple is going to require sandboxing. That story is so out of date that when I first heard it, I fell off my dinosaur.

      • by skribble ( 98873 )

        "...sandbox where multiple private companies publish application profiles and the consumer choice is maximized..."

        Like SSL certificate authorities? Yea there are no holes in that model.

      • I would much rather like to see a sandbox where multiple private companies publish application profiles and the consumer choice is maximized; that's a nice role for the AV companies to play, move from a blacklist to a whitelist model.

        The multiple authorities model hasn't worked out so well for HTTPS recently. This year a number of Certificate Authority companies have been compromised.

        Should such a company turn into Big Brother, limit the consumer choice and push it's own interests, the consumers can easily move to a different "security provider".

        "Security provider"? Most people have trouble reasonably choosing between rival electricity and gas providers. Or just couldn't be bothered. And that is for something they understand. What the fuck is a "security provider" to 99% of the population? It's an unwanted complexity that they don't understand, that's what. Trusting Apple to do what's reasonable

    • by l0ungeb0y ( 442022 ) on Thursday November 03, 2011 @12:42PM (#37936526) Homepage Journal

      How are they isolating developers? I develop on the Mac and constantly install development software all the time. Know how many development related bits I've had to install via AppStore? -- ONE -- The latest version of XCode after it went to public release.

      The AppStore is for CONSUMERS, there will never be a full lockdown because forcing every software writer to release through the AppStore would kill OS X as a development platform. Even XCode requires a whole bevy of gnu utilities. OS X is a full fledged UNIX and as such, you'll always be able to do *Nixy things such as wget/curl a file, gunzip, configure and make.

      What Apple does with their CoCoa Framework and native apps is up to them, but as long as they are a UNIX, they'll never have the ability to stop apps written in C, Java, Python, Bash, Perl, PHP or Ruby from doing whatever the hell they please.

      The day they do, is the day OS X leaves the Unix fold and becomes something else. And if that happens, you can bet your sweet ass that Apple will be dead within 3 years.

      • "OS X is a full fledged UNIX and as such, you'll always be able to do *Nixy things such as wget/curl a file, gunzip, configure and make"

        I wouldn't bet on it. Its entirely possible to make the kernel limit what a user can do above and beyond a chroot jail - SELinux does it already. That doesn't make it any less of a version of unix. All you'd see on the command line is the "Operation not permitted" error and that would be that.

        As for apple being dead if they messed about with the unix roots of OS/X , very un

        • Re: (Score:2, Troll)

          by l0ungeb0y ( 442022 )

          If they chrooted Darwin to the point that every app had to have Apple granted permissions to do *anything* on the list of AppStore sandbox privileges, then Apple would indeed be dead in a very short time.

          iOS is already stagnant in the Smartphone marketshare reports while Android keeps growing and gaining new product platforms. Granted, iOS still has a huge install base, but the day that Apache can no longer access the internet and PHP/RoR scripts can't access the file system or make network service calls, i

      • by Tetsujin ( 103070 ) on Thursday November 03, 2011 @01:19PM (#37937214) Homepage Journal

        The AppStore is for CONSUMERS, there will never be a full lockdown because forcing every software writer to release through the AppStore would kill OS X as a development platform. Even XCode requires a whole bevy of gnu utilities. OS X is a full fledged UNIX and as such, you'll always be able to do *Nixy things such as wget/curl a file, gunzip, configure and make.

        I believe this is true for the time being. However, using words like "never" and "always" is a bit short-sighted. Desktop and laptop computers have traditionally been fairly open platforms in terms of what the user is allowed to do - but there is no reason to assume this will continue to be the case. If someone wants to change that, it will be a slow, difficult process to change user expectations to a point where they accept that loss of control - but it can be done. People have already accepted mobile phones as a fairly closed platform, and some contend that phone use is displacing most "personal computer" use - which means that the experience people get with their phones is redefining users' expectations of interaction with their computers.

        OS X is currently a "full fledged UNIX" - this can change.
        XCode requires a bunch of GNU stuff - that can change.
        What do they gain from further restricting their platform? They gain a greater ability to simplify the user experience (which is a good thing for many users) and redefine various aspects of the OS that could be hard to do otherwise... And they gain status as a gatekeeper for the platform, a middleman who can extract money for every piece of software sold on the platform - much like what they enjoy on the iPhone platform, or what game console manufacturers enjoy.

        One possible approach would be to give developers the same level of control they have now - but marginalize them. Charge them an extra $300 for the version of OS X that lets them do developerry things, or block developer machines from accessing the app store (apart from developer tools) - things like that. Things that would yield the desired level of control over most Mac systems, simply because most users wouldn't want the disadvantages (additional cost or reduced capabilities) that come with a development-capable machine.

        I hesitate to say "Apple could do such-and-such" because I feel like that conveys the idea that I think this is likely to happen in the near future. My point is that it could, and it's silly to assume that it won't. The landscape of computing is changing, as it is bound to do over time. It's easy to assume that the status quo is some static, unchangeable thing, but it really isn't. Within the bounds of what users are willing to accept (even grudgingly, at first), the company in control of the platform can do whatever they like.

    • by Kohath ( 38547 )

      You don't know the future. Neither do "Apple fans". What's the point of arguing about what might or might not happen at some unknown time in the future? What's the point of getting upset about something that hasn't happened and hasn't even been proposed?

      Is reality too boring that you have to make up stories and be upset about them? Or is reality too upsetting that you have to make up stories to feel better? Why should anyone else care one way or another about the your made-up stories?

  • by Anonymous Coward

    Why, at a technical level, is this so bad?
    Because... uhh... uhhh.... uuhh... SCREW Apple!!

    Haters gotta hate.

    • by IamTheRealMike ( 537420 ) on Thursday November 03, 2011 @12:34PM (#37936352)

      Sandboxing applications isn't so bad, and I think this is correct and inevitable. The fear comes purely from the fact that Apple has historically been very abusive with its app store policies, they aren't there purely to ensure security but are also used to simply crush apps some Apple executive didn't like, eg the "no competition" clauses.

      Given Apples flaky approach to app store approvals, it's not unexpected that many people see this as the end of the Mac as an open(ish) computing platform. Given there aren't very many platforms, Microsoft tends to follow Apples lead these days, and Linux has never overcome its problems to go mainstream - that's a cause for concern indeed.

      The good news is that there is Android, which gets it right - strong app sandboxing with an opt out checkbox you can tick if you want to. And it's open source so even if it stops being right tomorrow (unlikely), it's still a strong foundation others could build off. The bad news is that Android does not run on laptops or desktop machines, and does not have the enormous collection of industrial-strength apps like Photoshop, Office etc that MacOS/Win32 does.

      • Why even mention Android? We have Linux, Windows, BSD, and other operating systems for the desktop. Also, this ONLY applies to applications sold in the App Store. You can still download directly from a vendor, or buy a DVD/CDROM from your local software retailer.

    • by SuricouRaven ( 1897204 ) on Thursday November 03, 2011 @12:35PM (#37936382)
      At a technical level, it isn't. Common-sense security is being applied: No app should have permissions to do something it can't show good need for. The fear isn't about technology, it's about Apple's business model, which is now built upon restricting the capabilities of their products in order to drive the users towards Apple's own supporting services. A successful business model, but one many regard as exploitative, detrimental to the users and a bad thing for the culture built around access to technology.
      • No app should have permissions to do something it can't show good need for.

        The problem is that there exist things that an app can show good need for that are not possible using the machine-readable need-showing mechanism that Apple is set to provide.

        • The problem is that there exist things that an app can show good need for that are not possible using the machine-readable need-showing mechanism that Apple is set to provide.

          That's OK, they can let Siri do it.

        • The problem is that there exist things that an app can show good need for that are not possible using the machine-readable need-showing mechanism that Apple is set to provide.

          Which a user can still install outside the app store.

          Eventually the permission models will encompass enough functionality it will be possible - but in the meantime users get a fleet of far more secure applications and a far more secure system.

          The only downside is a handful of applications that cannot be sold through the app store - but

          • There is no downside today. I've not seen anyone express concern about this *today*. The fear is the direction this is heading.
      • by skribble ( 98873 )

        "...detrimental to the users..."

        I've yet to see an intelligent balanced argument to support this general statement. Yes, there have been things here or there that may have adversely affected some users in some way, but usually as a trade off for helping more users or providing more helpful services.

        Anyway let me fix this for you... I believe what you meant to say is "...detrimental to certain ideologies..."

        It's perfectly natural to be worried when the illusion of control is wrestled away from you, but the q

    • Why, at a technical level, is this so bad?

      Ok, for starters it's another innovation killer. By Apple bolstering it's control of the platform, in yet another authoritarian way, it raises the frustration level for the developer and many would-be developers. "Code. Build. Innovate.". Yeah, riiiight.

      Secondly, if I'm a developer doing something new and cool, maybe I don't *want* to reveal how I'm doing it. Maybe I don't want to make it easy for anyone, including Apple, to copy my application. It's my code, not Apple's and there are several incidents wher

  • Problem? (Score:4, Insightful)

    by AdrianKemp ( 1988748 ) on Thursday November 03, 2011 @12:28PM (#37936250)

    I fail to see any problem with this.

    I'm actually far happier when apps are clean and well controlled in terms of what they put where, Apple is providing an assurance that this *will* be the case for officially approved apps.

    Good on them.

    Whether or not they eventually disable applications from outside the App Store is completely irrelevant to this move.

    • Re:Problem? (Score:5, Interesting)

      by tripleevenfall ( 1990004 ) on Thursday November 03, 2011 @12:33PM (#37936334)

      As much as people like we /. denizens will gripe about this, for the average user it's a good solution. Disable by default the installation of unapproved apps. Allow users to opt out of that feature if they so choose.

      For most users, who will never figure out how to enable non-market apps, or will have no desire to anyway, this makes their PC much more secure. For "power users", it's trivial enough to live in the old world.

      • For most users, who will never figure out how to enable non-market apps

        That's only if companies like Adobe and Microsoft start selling their apps in the App Store.

    • by tepples ( 727027 )
      Does a "[n]eed to access hardware using something else than USB, for example Thunderbolt, FireWire or Bluetooth" or "to read and write files in a known location on a network disk" or to use the "Apple events" needed for AppleScript support necessarily imply that an app is not "clean and well controlled"?
      • No, but it does means that the app checks a lot of the same boxes as an app that is not "clean and well controlled".

      • by slim ( 1652 )

        Of course not, but the point is that the installer tells you what resources the app is demanding access to, and you have the choice to say "yeah, that makes sense", or "no, why the hell does it need that?"

        Let's say you install a text editor, and it says it needs the ability to add/remove user accounts -- you'd raise your eyebrows.

    • Yeah, I don't think this is any more of a risk of "lockdown" than Apple having an App Store at all. Apple is distributing applications and, in effect, endorsing the applications it distributed. It sounds like mostly they're just asking developers to give them an idea of what security issues the application might have.
  • Apple is a business (Score:5, Interesting)

    by linumax ( 910946 ) on Thursday November 03, 2011 @12:30PM (#37936280)
    And they're here to make money. There seems to be a large market for people who want pretty appliances with certain "limitations" that work painlessly. Limitations is in quotes because it's a limit to myself and many on Slashdot, but not to most casual users.
  • by Geoffrey.landis ( 926948 ) on Thursday November 03, 2011 @12:32PM (#37936310) Homepage

    So, is this actually unreasonable? Seems to me that if you don't want machines to be pwned, it would be nice to have somebody look over the ap before it starts controlling processes outside its sandbox. Sudo privilege is nice to have, but it's also something you don't want to give away without oversight.

  • This is stupid. Virus and Trojans are not coming through the App Store. People are installing pirated software that has been infected or purposely contains a trojan. If people stop installing pirated software or being dumb and installing software without questioning it, this problem would go away in the MacOSX space.

    • If people stop installing pirated software

      Define pirated software. Is VLC Media Player pirated software because it is an independent implementation of a well-known media codec? Is a game like Quinn or NullpoMino pirated software because it implements the same rules as a well-known commercial game?

      • I think you are twisting his words around to try to make an off topic discussion on piracy. He did say (emphasis mine):

        If people stop installing pirated software or being dumb and installing software without questioning it, this problem would go away in the MacOSX space.

        I would put VLC Media player in the be smart about where you download it from portion of his comment.

    • This is stupid. Virus and Trojans are not coming through the App Store

      No, where they usually come through is data payloads to applications.

      Which is why it's quite smart to not let applications have write access all over the system - not even all over your home directory.

      There's already the user/system layer of protection, this just adds one more layer and greatly reduces the usefulness of corrupting data to an application as an attack vector - VERY important in an age where more and more applications have s

    • Simply not true. Most viruses and software are coming from web site now a days. Or trojans is emails.

      As someone pointed out, making this behavior the default is the first step. It will be a slippry slope.

      1) you have to do it their way to get published in the app store, but users can run any app.
      2) then you have to opt in to run any app
      3) then you can't get support on OS issues if you have opted in and have non app store apps installed
      4) then you cant install non app store apps.
      5) viola, you have the iphone.

    • This is not to prevent trojans from coming from the App Store, it is to decrease the attack area of apps if exploits are found through them. For example suppose an app registers an URI handle, but does not properly sanitize the data before processing it leading to an arbitrary code exploit. It would still have to bypass the sandbox to further infect the system. Yes, pretty much all malware software is based on trojans. But that doesn't mean that ignoring other risks is a good thing.

      The biggest problems with

  • OMG TEH EVIL APPLE (Score:5, Insightful)

    by wumpus188 ( 657540 ) on Thursday November 03, 2011 @12:32PM (#37936318)

    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.

    • 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 tepples ( 727027 ) <tepplesNO@SPAMgmail.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 Roogna ( 9643 )

        Mind you, Apple has a way for Developer's to provide feedback for APIs they need. If enough enter tickets requesting a API be sandboxed, it'll show up at some point. This has proven true on iOS side as well. If enough dev's put in requests for an API for something, it usually does show up, eventually. This isn't always a quick process, but the more feedback they get, the more likely it will turn up at some point.

    • Yes, and the Android model sucks. I have to either grant the app all the permissions it asks for, or refuse to install it. There's no way to say "yes, install it, but don't let it access my address book."
  • Great Security (Score:5, Insightful)

    by dogmatixpsych ( 786818 ) on Thursday November 03, 2011 @12:33PM (#37936346) Journal
    This is very good practice for applications in the Mac App store. It's a huge security feature. Now, if Apple ever locks down the Mac to allow only applications from the Mac App Store (they won't), I'll give up Mac and go to Linux full-time (I use Macs for neuroimaging research and definitely don't have the applications/tools I use available through the Mac App Store; it would be nice to have a lot of them on a central repository though like Neurodebian {I virtualize that on my Macs}), but in the mean time I'll stick with my Macs. This is a wonderful security feature for applications given stamps of approval from Apple through the Mac App Store. Yes, there might be other security issues introduced through OS X issues but in general this is a positive step forward. Again, I'm not suggesting all applications should be sandboxed, I just think it is good practice for the ones distributed through the Mac App Store.
    • Exactly. I won't deal with Apple, but this is good for the unwashed masses in many ways...except one.

      One tiny breach of the app store and you could suddenly have millions of zombie/compromised Apple devices out there. But they would all be trusted by everyone. Would Apple admit a breach and destroy the trust they've built?

      Won't happen? Dream on. Sometimes a certain lack of trust is good.

  • by Hentes ( 2461350 ) on Thursday November 03, 2011 @12:35PM (#37936386)

    This would be an important security feature if users could force it for any program.

    • This would be an important security feature if users could force it for any program.

      The problem there is that if the program wasn't written to be well-behaved, it may trip various security rules by fairly harmless processes of its normal operation.

      For instance, if a Windows program were to store a bunch of data in its directory in Program Files - on older versions of Windows this would be fine (because users commonly had administrator-level privilege and thus also write access to the application's directory in Program Files) - but in a more secure setup on a more recent version, this would

  • by Trolan ( 42526 ) on Thursday November 03, 2011 @12:36PM (#37936406) Homepage

    Sandboxing applications is a common security model on Unix systems, so why is this a bad thing on desktop apps as well? The App Store apps already had restrictions on where you could put your executable. This just codifies other accesses into a model where the developer sets up the privileges the app requires instead of leaving it at the free-for-all it is now.

  • by stating_the_obvious ( 1340413 ) on Thursday November 03, 2011 @12:40PM (#37936464)
    The future of all applications will be individual sandboxes. Why the hell would you have perimeter security (show your credentials to access the enture kingdom) versus a police state (show me your papers) that denies all privileges not specifically granted. I'm not saying I want to physically live in that world, but I definitely want my computers operating in that world
  • Ummm... good? (Score:5, Insightful)

    by Just Some Guy ( 3352 ) <kirk+slashdot@strauser.com> on Thursday November 03, 2011 @12:40PM (#37936484) Homepage Journal

    So a free Twitter app isn't allowed to take screenshots while I have my checkbook app open? I'm OK with that. Every one of those restrictions seem perfectly reasonable and good.

  • by GWBasic ( 900357 ) <`slashdot' `at' `andrewrondeau.com'> on Thursday November 03, 2011 @12:41PM (#37936492) Homepage
    I do think some kind of sandboxing would be nice; for example, blocking Skype from automatically installing plugins in every browser under the sun without asking my permission. It's important that sandboxing doesn't prevent programs from being useful.
  • So let me get this straight, If apple does only allow app installations from the App Store, rather than allowing you to install whatever you want on your computer. What does this mean for anti-trust precedents set against Microsoft? The lawsuits fighting against them bundling IE with windows. Microsoft never wanted to deny you the right to install another browser, they simply bundled their browser with their OS, and got sued for it. Apple did it, nobody batted an eye. Apple prevented you from installi
    • by Pope ( 17780 )

      Apple isn't a monopoly. QED.

      Also note that they have NOT restricted non-App Store programs from being installed.

    • What does this mean for anti-trust precedents set against Microsoft?

      Nothing. Apple is not a monopoly, anti-trust doesn't apply, they can do whatever they want until they reach, whatever, 90% market saturation. Also, what you and the summary suggest, only allowing Mac AppStore installations, will never happen.

  • If this prevents companies like Adobe and game developers from installing crappy insecure DRM measures all over my machine, then I welcome this.

    90% of the population won't notice anything different, where as the other 10% who happen to be tech savvy will bitch and moan about the walled garden until there face turns blue.

  • by slim ( 1652 ) <john@hartnupBLUE.net minus berry> 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 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.

  • ... is when I abandon the platform. As it stands, only 3-4 Apps on my Mac are from the MAS. Unless I can get VMWare, MS Office and other basic desktop apps on my system, the platform is not meaningful for my work.

    Which is probably the reason why it will never happen.

  • 'Paging the Anti-Trust Division, please...'
  • My understanding is that applications won't be able to see other users's files.

    Sounds like UNIX to me. And, gee, that's been around for only 40 years.

  • It is about time. The old goal of "protecting the system from the user" is obsolete. A PC is owned by the user - the user is not the enemy.

    Instead, the data needs protecting from rogue applications. Not everybody will recognise a trojan even if the writing is on the wall, and even an expert may not have the resources to be sure. Sandboxing removes any doubt - an application has to say what it wants to do.

    So for once, this is actually a useful development.

  • 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.

One man's constant is another man's variable. -- A.J. Perlis

Working...