Mac App Store apps must implement sandboxing as of March 2012

http://developer.apple.com/news/

by kinetik • 15 years ago

78 68 15 years ago

developer.apple.com

LeafStorm• 15 years ago

Apparently, I am not authorized to view any information on sandboxing besides "[a]s of March 1, 2012 all apps submitted to the Mac App Store must implement sandboxing" and that it "is a great way to protect systems and users by limiting the resources apps can access and making it more difficult for malicious software to compromise users' systems."

Apple's developer relations with anyone who doesn't want to fork over $100 just to read the docs are really poor.

alastairpat• 15 years ago

http://developer.apple.com/library/mac/#documentation/Genera... provides pretty much everything on sandboxing from a non-architectural, developer point of view.

biot2• 15 years ago

It's free to register as an Apple developer and your ID will then work:

http://developer.apple.com/programs/register/

Though to your point, I'm not sure why Apple requires someone to login just to read the docs.

fleitz• 15 years ago

No it isn't. I'm an iOS dev but not Mac and I can't read the docs. You have to pay to read the docs and find out what sand boxing entails. But I suppose if you're not distributing through the App Store why would you even care?

ewoodrich2• 15 years ago

I wish I could find better documentation for this. I'm curious how their sandboxing implementation will work.

I guess my "membership level" can't see the tech docs.

davidcann• 15 years ago

Did you even look? It's publicly available:

https://developer.apple.com/library/mac/#documentation/Secur...

ewoodrich2• 15 years ago

I did, but only on the landing page of the OP's link, which was forbidden based on my dev membership.

Thanks, that's what I was looking for.

kstenerud• 15 years ago

Click top link, follow the "App Sandbox Page" link from Apple's page (https://developer.apple.com/devcenter/mac/app-sandbox/), get redirected to https://developer.apple.com/devcenter/ios/unauthorized/

kennywinker5• 15 years ago

It's time to write the eulogy for application automation and inter-application communication on the Mac.

AppleScript (beast that it is) was innovative when it was created, and still has not been replaced. Automator is built on AppleEvents, and with sandboxing will come a sharp decline in the number of applications that can receive AppleEvents and the extinction of apps that send them.

sipefree• 15 years ago

Not at all!

Sandboxing brings with it XPC, which is an IPC framework for doing very fast and awesome message passing.

It's got some great features for separation of privileges. For instance, you might have an XPC sandboxed process for, say, rendering a H.264 video to a buffer. That process never gets access to the filesystem, the graphics card, or anything apart from the strip of memory that contains the file, and the buffer it has to write its pixels to.

Then you can use this to render a H.264 video in your application, and if a buffer overflow is found that could lead to a video containing shellcode to be executed, you have no fear that bad things can happen to the filesystem or users' stuff.

If I'm not mistaken, I'm pretty sure XPC is how they implemented the crazy feature where you open a QuickLook window on an image or something in the Finder, and if you it the Open with Preview(.app) button, the Finder's QuickLook window turns into a Preview window.

kennywinker5• 15 years ago

I tried very hard at WWDC this year to get a comment on this. Nobody would clarify if XPC could be used in the way Apple Events are...

All the documentation I could find were about splitting your single app into multiple processes, and using XPC to communicate between them. Does XPC provide a way to query the interface of an app you don't own? Can I ask for an XPC "dictionary" a la AppleScript?

Groxx2• 15 years ago

/me tries the quicklook -> preview thing

That's kinda cool... never tried that before.

But yeah. Sandboxing does not at all imply not-scriptable. It tends to imply breakage with older systems of scripting, but that's about all, and only until wrappers are made.

teilo• 15 years ago

Time to settle down, people. This is not the bad news you think it is. Please take the time to read what exactly is entailed in Sandboxing a Mac App before you presume this is a restriction on your freedom. You can start here:

https://developer.apple.com/library/mac/#documentation/Secur...

The vast majority of apps on the App store can be sandboxed without effecting their functionality in any way.

Sandboxing on OS X is not like Sandboxing on iOS. You can still access all your files. Your app just can't do it without asking. You can still send Apple events to other apps - you just can't send them to whatever apps you feel like. They must be defined, and permission granted via entitlements. True, you cannot access another applications preferences. However, an application can present an API that other applications can access.

In other words, this change forces apps to be designed much more securely. It reminds me of the Android permissions model.

kennywinker5• 15 years ago

"Sending Apple events to arbitrary apps With App Sandbox, you can receive Apple events and respond to Apple events, but you cannot send Apple events to arbitrary apps."

"By using a temporary exception entitlement, you can enable the sending of Apple events to a list of specific apps that you specify..."

The word at WWDC was temporary exceptions are temporary and just there to ease the transition to sandboxing. I.e. they will be REVOKED at some point in the future.

natesm3• 15 years ago

> You can still access all your files. Your app just can't do it without asking.

Sort of. You can't access files across restarts of your app right now. So something that needs to maintain a database of files in the filesystem (say a music library) will be able to access them when the user adds the files, but then will stop working after you restart.

The only way around this is a "temporary" exception - they absolutely need a permanent solution for this situation.

DrJokepu• 15 years ago

I'm a 100% behind the idea of sandboxing, one of my apps in the Mac App Store already comes with sandboxing enabled even though it's not required yet, but I feel like the current way to do it can be very limiting. Some perfectly legit applications would be inherently broken with no easy way to fix them. Heck, even Xcode would be broken as you only open the project file directly, how could you edit the source files in the project individually without opening them one by one?

The only way I can think of is having the whole project, including the source files in a single bundle but that would break everything currently out there.

elHeffe• 15 years ago

An I wrong in thinking this sounds like app armor for Linux? A good thing if implemented properly.

wes-exp• 15 years ago

Seems so: "In Mac OS X v10.7 and later, placing your application in an app sandbox is a great way to minimize the potential damage caused by successful exploits"

http://developer.apple.com/library/mac/#documentation/Genera...

droithomme2• 15 years ago

Putting my applications in a sandbox doesn't really prevent my application from doing exploits because my applications are not malware to begin with. Well behaved applications that are not malware are already not malware. The real issue is what about malware, will this stop them. Well, obviously malware authors are not going to put their applications in a sandbox. They will continue releasing them as before.

And so, obviously, this system won't work unless all software is sandboxed, not just the normal innocuous non-malware that didn't need to be in the first place.

It's the same principal where you can't stop gun crime by banning only law abiding citizens from having guns. You have to completely eliminate all guns or it doesn't work. All or nothing.

To me, this tell me where this is headed. Obviously total sandboxing of everything has to be done for this to be effective at all. And with total sandboxing of everything we no longer have a desktop computer that can be used for general productivity, we have an information appliance that provides a nice consumer experience.

extension2• 15 years ago

This is the only sensible security model for third party software in the world of today. Actually, this is the only sensible security model in the world of ten years ago. Windows has been endlessly criticized for not sandboxing apps. It's gotta be done and Apple is doing the transition the way that has always worked for them: fast and ruthless.

cageface• 15 years ago

The real question is this: Is Apple going to eventually make the app store the only way of installing apps on a Mac? I think this is likely and if so is going to be the end of the line for me as an Apple customer.

lukifer3• 15 years ago

I draw the line here too. I accept the control tradeoff on iOS because I view them as appliances, not computers, and there are upsides to the curated experience. But if I can't fully control my primary computing device, I'm out. (I'd be okay with the machine shipping in "grandma mode", so long as there's an official way to disable it completely.)

jayfuerstenberg• 15 years ago

Your opinion is valid. There is one way to disable it as these rules still only apply to apps sold via the MAS.

Anybody can release software outside of it and just forget about Apple's rules.

pyre2• 15 years ago

Wait until you void your AppleCare if you disable 'grandma mode.' Or until any third party decides that they will only support Macs in 'grandma mode.'

gte910h• 15 years ago

Huh? They're just talking about selling things in the Appstore.

They're not stopping people who don't distribute this way.

glassx3• 15 years ago

Actually, the real question is: what would Apple gain from killing 90% of the app ecosystem?

There are some apps that can't be really sandboxed (Little Snitch, virtualization tools), some apps you can't sell on the AppStore (video/audio/photoshop plugins) and there's even Apple apps that aren't available there yet (Logic, Filemaker, ).

Also, Macs are the only way to write OS X and iOS apps, it would make the barrier to entry way too high for most people, shutting off potential developers. How would you write, say, your Rails backend to your iOS app, on your Mac, if it was locked down?

But yeah, I would jump ship to Linux immediately as well.

dman• 15 years ago

A 30% cut of the remaining 10%.

Groxx2• 15 years ago

Gain? 30% of all application sales, instead of 30% of 10%.

I don't think they'll lock it down to the app store either, but there are plenty of essentially-reasonable reasons why they could/would.

extension2• 15 years ago

Locking down OSX would be an epic technical and social battle. I can't think of any reason they would go to war with their power users just to do that, especially since they already have a curated platform. They probably just want to give novice users a safe, curated experience by default.

kennywinker5• 15 years ago

I can absolutely see them doing this... and SOON. Give the MAS ecosystem a year, two at most, to mature.

There WILL be a switch somewhere, in the system prefs... a defaults write command... why? Because of Adobe, ProTools, Microsoft, and to a lesser extent stuff like homebrew and macports.

lukifer3• 15 years ago

Though there have been many disturbing trends in the evolution of the App Store(s), this one is actually quite mild, if not welcome. Honestly, it's always unsettled me a little that any software can just start arbitrarily scribbling bits to the hard drive. (The system folder is protected, but my data isn't.) The concern is only a little about malware, and mostly about buggy code.

All the sandbox requires is that apps only have access to files when the user initiates the action. And unlike most App Store policies, you're also allowed to request specific exceptions as needed by your app, and I'm expecting they'll actually be reasonable about it. [1] This creates more work for developers, but I think overall these changes will help keep users' data safe.

As also mentioned in this thread, these changes have big implications for inter-app communication. But sandboxing doesn't take the capability away; it just requires devs to do more work, again in the name of user security. There will be a big usability hit on apps which don't see regular updates, and apps whose developers neglect to update this aspect of their apps. But the same capabilities will exist, and eventually most apps will catch up to the new norms.

[1] Although if Apple starts making stupid rejections and standing by them, then I take it all back.

benatkin2• 15 years ago

> Although if Apple starts making stupid rejections and standing by them, then I take it all back.

That's a given.

ugh4• 15 years ago

Apple typically didn’t stand by stupid rejections. They made them, didn’t stand by them.

seanalltogether• 15 years ago

[1] They are only handing out temporary exceptions

http://developer.apple.com/library/mac/#documentation/Miscel...

idspispopd• 15 years ago

You're quite right, while malware is a threat often the biggest issues come from unforeseen bugs. Users with a long memory may remember the iTunes 2 update fiasco. where Apple's own update script was responsible for wiping user data.

The below link explained the error, and how it only occurred on certain volumes: http://www.xlr8yourmac.com/OSX/itunes2_erased_drives.html

dgallagher• 15 years ago

This SO question raises an interesting issue: http://stackoverflow.com/questions/7419912/how-will-lions-ne...

What if your app uses Python to perform IO? What if you wrote your code using PyObjC? Is there any way to sandbox that, or are you out of the Mac App Store for good?

makecheck• 15 years ago

That's a very good question.

I use Python a lot and I combine it with C++ and Objective-C to build a very complex application. While it looks like a regular app and behaves like one, underneath it starts out as a Python interpreter that runs a script and loads compiled libraries. It's a model that works extremely well and I hope it continues to "just work". Sure, it's unconventional and I'd understand if Apple didn't expect most things to work this way, but I hope they don't just break it completely for me.

jensnockert2• 15 years ago

It should work just like for Objective-C applications, it isn't implemented in Cocoa but at a kernel level.

The sandbox has been around since Tiger (or at least Leopard) and with a proper configuration it works fine with Ruby/Python.

mattgreenrocks• 15 years ago

I thought this was supposed to be done by the end of this month?

I'm excited, even if only for the prospect that anything I install from the App Store can't lodge itself everywhere in my system.

Too• 15 years ago

Will this have any effect in practice or will it just be the same as the different trust levels in .NET? The functionality for sandboxing is built in it's just that nobody uses it or knows how to test or enforce it. (with the exception of sysadmins).

In any case i welcome all sandboxing, this is even something i would consider switching from windows because of, given that it actually works out good. Let's take an example from yesterday, i want a simple pdf-merge program. As it is now i have to spend 20 minutes researching a program on forums and other sites before i even install it to see if it's safe and everything. Compared to just installing and see if the result works. This is also why web apps are so popular, you can try hundreds of them with 0 risk for your other data.

ghshephard• 15 years ago

If this means that I can be reasonably certain an application that I purchase from the App Store will be prevented from screwing up parts of my system without my permission - then, as a user, I'm all for it. One day, in the future, apps will run in a chrooted/isolated virtual environment, with some actual guarantees that they are _incapable_ of touching anything but their sandbox, regardless of developer intent. Until that day though, this seems like a reasonable evolution to that world.

Perhaps it speaks to my paranoia - but I've always been unnerved by the concept that an application can basically do anything to the OS that I can from from finder/shell. I have to believe that this sandboxing will reduce the potential for malware doing damage to the OS.

The question I have is - will I be able to give applications like "Backblaze" the ability to read (but not write) from my entire set of user folders? If so, then that's the best possible case. Puts the power to control damage that an application can do in my hands.

jbrennan• 15 years ago

> The question I have is - will I be able to give applications like "Backblaze" the ability to read (but not write) from my entire set of user folders?

Sure. This sand boxing only applies to App Store apps (for now at least). I imagine so long as you can install non-Appr Store apps, you can also have non-sandboxed apps.

ricg2• 15 years ago

The end of utility apps? What makes (used to make?) the Mac such a great platform is that apps integrate seamlessly. Making them work together in new ways that were not anticipated by the developer is incredibly powerful (Unix philosophy anyone?).

Sure, sandboxing will allow your app to talk to another app, but only if you request permission beforehand. But what if the app my app wants to intact with has not been written yet?

What about application launchers like QuickSilver, Launchbar, and all the hundreds of other utility apps?

Only allowing sandboxed apps will change the nature of apps that we will find in the app store from "utility" shifting to "just-do-one-thing".

And about the question about whether the Mac App Store will become the only way to install apps on the Mac: the question is not if, but when.

natesm3• 15 years ago

This has already sort of happened. Apps are forced to have some sort of permanent presence now. In the past, you could be running many of these and still have a clean menu bar. Now, you have to have an icon for Growl, an icon for Quicksilver...

ricg2• 15 years ago

Sure, but that's not restricting functionality. Sandboxing on the other hand will simply mean that those apps won't get into the App Store in the first place.

pavlov• 15 years ago

I've been making Mac apps for nearly a decade now. I wrote a summary and opinion piece on this:

http://lacquer.fi/pauli/blog/2011/11/why-the-mac-app-sandbox...

(HN discussion link: http://news.ycombinator.com/item?id=3191021)

startupcomment• 15 years ago

Now if only they can implement something like this for Safari so that individual browser pages are sandboxed from each other, as is the case in Chrome.

Mac App Store apps must implement sandboxing as of March 2012

Related Stories