Slashdot Mirror
Apple To Require Sandboxing For Mac App Store Apps
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."
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.
Carol vs. Ghost
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.
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.
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.
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.
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".
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.
Dewey, what part of this looks like authorities should be involved?
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.
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.
You can install an application from anywhere. Apple is simply providing application writers a mechanism to help ensure user security (that you can also use in building non app-store apps), and a channel for people to get applications that they know will have less potential impact on the system if there's a security issue. If I get a computer for a grandparent and say "buy applications from here" then they are substantially better off and I can rest easier knowing it's less likely the system is compromised, even if any given application is compromised.
I would say what is restrictive is the notion that users should have to understand computers well enough to secure them. That is the real prison which we have forced millions to endure for years. A computer that people can use to a great desire without worrying about how to "maintain" it is liberation for 99% of computer users on the planet.
"There is more worth loving than we have strength to love." - Brian Jay Stanley
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.
I am TheRaven on Soylent News
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 if you want more details.
Also, according to MacWorld, the original deadline was November (Source: MacWorld). 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.
Check out my sci-fi/humor trilogy at PatriotsBooks.