OS X Lion App Sandbox and its implications on applications

sandboxPhoto credit: livingindryden.org

I’m very excited about the new operating system and the APIs it holds for developers.

One new feature that is going to be very popular amongst users and holds real benefits for them is the App Sandbox.

What is App Sandbox?

Entitlements

Basically, the App Sandbox needs developers to specify what kind of access to user data an application they create needs.

You basically start with no privileges (so called “entitlements”) at all and work your way up for what your app needs. 
Does it have open or save panels? You need an entitlements for that.
Does it need access to the network? More entitlements.
Does it need to access iCal or Address Book? Even more entitlements.

Apple states there are currently 15 entitlements, but the list may change in the future.

Containers

For data saved by applications, like preferences files, Core Data storage, “Shoebox” data, basically everything except Documents the user saves or are autosaved by OS X Lion, each application gets its own Container in /Users/yourname/Library/Containers/, like /Users/matthias/Library/Containers/at.EternalStorms.ScreenFloat/

An application that has no entitlements for file system access can not access anything beyond that folder without the user’s consent (a user can give their consent with selecting files in open or save panels or by drag’n’dropping items onto or out of the sandboxed application).

Deny, deny, deny!

Anything an application requests it doesn’t have the proper entitlement for gets denied by a process called sandboxd, the sandbox daemon. It manages the sandboxed applications and their access to things they are or aren’t entitled to.

This is what your Console looks like when something gets denied:

27.07.11 16:56:14,480 sandboxd: ([2460]) screencapture(2460) deny file-read-data /usr/sbin/screencapture

XPC

XPC helps take the sandbox paradigm even further, making apps even more secure. Instead of having one executable that does it all (access the web, access iCal data, access Address Book data, write stuff to disk, read stuff from disk), a developer splits these tasks up and basically creates for each of these operations a executable with just enough entitlements to do its work.

So if you have an application that can access your Address Book and the web, there’s nothing from stopping the app, had it been compromised, from sending that data to a server.

However, if you have two different executables, one with just the Address Book entitlement and another with just network access, it’s not that easy anymore for intruders to do their dirty business.

XPC lets these two executables talk to one another, inside their shared sandbox.

What is App Sandbox good for?

Something that has been said a thousand times in the WWDC sessions to make abundantly clear what App Sandbox is good for:

It’s a last line of defense against evil-doers.

If an application has been compromised, it can’t do anything beyond its entitlements. That’s a very good thing.

So what does it all mean for users and developers?

Users

For users, it’s a great thing to have in terms of security and privacy of your data and I think every user should be excited about it. I know I am. It’s a great solution to a problem that has been dragging on too long, and Apple stood up and took a shot at it, and I think they did very well. For the most part.

In terms of what app developers will be able to make for those users, well, that’s another story which I’ll explain next.

Developers

In general, for most cases, developers won’t have any trouble with the App Sandbox. Version 1.2 of ScreenFloat – which is currently in Review for the App Store – already is a client of the sandbox and I ran into no trouble with adopting the entitlements, what so ever. It does what it does, just like before, but now, it’s safer, and I’m very excited about that.

What worries me, however, and, judging from what I’ve read on Apple’s developer forums, worries quite a lot of other developers as well, are the so-called temporary entitlements.

Temporary entitlements are for certain cases where it’s not really safe to do something, but Apple hasn’t figured out a safe way to let the app do it yet, so they made an entitlement for it. A temporary one.

Let’s take, for example, iTunes. There are a lot of applications out there that can “remote control” iTunes with global hotkeys.
In the background, the application is sending out an Apple Script, or doing its work over the Scripting Bridge, or are sending Apple Events directly (Apple Scripts and Scripting Bridge work with Apple Events in the end, but it’s at a higher abstraction level API wise for developers like me, who have no idea how to create Apple Events in the first place).

For this case, Apple has created a temporary entitlement. Alright, so it works.

What bothers developers however is the term “temporary”. What _is_ temporary, exactly? Will there be a replacement once the temporary entitlements vanish?

Let’s look at a perfect example for this:

GimmeSomeTune and the App Sandbox

Some of you might have read it on Facebook, others may have on twitter, for those of you who haven’t, here’s what happened:

I’ve halted development on GimmeSomeTune because of the temporary entitlements, more so because of the questions I asked above that have yet to be answered by Apple.

But let’s take it one step at a time:

GimmeSomeTune gets notifications with userInfo payload objects from iTunes. That’s no problem yet, since iTunes is yet to be sandboxed. But once it is, it can only send notifications without userInfo payload objects, and that object contains all the necessary information, like Title of Song, Album, Artist, etc.

So GimmeSomeTune, in its current form, could work for some time, until Apple decides to sandbox iTunes. Boom! Rien ne va plus.

GimmeSomeTune downloads artwork and lyrics and sends them to iTunes through the Scripting Bridge. The Scripting Bridge is essentially sending Apple Events to the app you target, in my case, iTunes.

The sandbox allows for Apple Events to be received by an application (without entitlements), but can not send any, without the temporary entitlement. When the entitlement is no longer valid, the main functionality of GimmeSomeTune breaks. Boom! Rien ne va plus.

So what it comes down to is this:

GimmeSomeTune would work right now in its current state, with temporary entitlements and hoping that Apple will never sandbox iTunes so it will continue to send notifications with userInfo payloads (which is doubtful, since iTunes is your digital hub and all, so they’ll be sure to sandbox it at some point, I guess).

But what happens if iTunes was sandboxed?
GimmeSomeTune would break, it would not know what song is playing in iTunes and hence wouldn’t download information and send it to iTunes, rendering the application useless.

And what if the temporary entitlements go away without a proper replacement API?
Again, GimmeSomeTune would break and it couldn’t send downloaded data to iTunes anymore, again rendering the application useless.

Why not just release it and hope for the best?

Sure, I could release GimmeSomeTune with temporary entitlements and hope they stay around forever or that there’ll be a replacement API for them.

But I have to consider what happens if they don’t (which is, in my opinion, 100% certain) – angry users, having paid for software that doesn’t do its job.

I am not willing to take that chance. I will wait to see what Apple comes up with.
And if there is a replacement for temporary entitlements in the works, and when I’m certain GimmeSomeTune will work with it, without the fear of having the application break at some random point in the future due to functionality that is ripped out from under it, only then can I release GimmeSomeTune with confidence and the knowledge that its users will be able to actually use the app.

And I believe this is the right choice.

Sandbox at its finest

Would you like an example of what kind of apps are completely unsupported in the sandbox environment?

Applications that change developer-signed files inside of app bundles that are a) developer-signed and b) running in the sandbox environment.

May I present the worst case Scenario: PresentYourApps

Some of you may know this little app of mine. PresentYourApps lets you hide the menu bar and / or dock for applications you specify, making more screen real estate available. Or at least, it _let_ you.

On OS X Lion, it works some of the time, but I highly discourage you from using it on that system, and I will take down the download link in the next couple of hours.

I discourage you, because it breaks apps you use it on.

I got an e-Mail from a user who tried it on Preview.app on Lion, and after he restarted Preview.app, it crashed on launch. Luckily, PresentYourApps keeps backups of the file it edits, so the user could make Preview.app work again, but it was scary.

Well, PresentYourApps has been long overdue and begging for an update, but because of these circumstances, I decided to discontinue working on it all together and removing it from my website, since it will do more harm than good on Lion systems.

 

If you have any thoughts regarding all of this, or GimmeSomeTune especially, please be sure to leave a comment or contact me in any other way!

Thank you kindly for reading,
Take care,
Matthias

About these ads

38 thoughts on “OS X Lion App Sandbox and its implications on applications

  1. What can “we” do as users of your great app.
    I have switched to lion and wait with baited breath for Gimmie….
    What can I say to apple that might hurry up there process?
    I mean I know they won’t listen directly to me. To them I’m just some fool in the rain.
    But I/we can still try.

  2. That’s probably the worst news of this 6 month. I was waiting the upgrade of gimmesometune and I was disposed to pay for it.

    I hope in the future you find a solution…

  3. [...] Right now Apple has an interim fix with scripting applications like iTunes called temporary entitlements. These are ways to get through the sandbox that really aren’t safe but for which Apple’s not come up with a good alternative. Applescripting is the biggest example of an unsafe practice Apple is allowing. The very emphasis from Apple on temporary doesn’t exactly inspire confidence here. Quite a few developers who utilize AppleEvents in their applications are either slowing development on those aspects or dropping them altogether.  (See for example here) [...]

  4. oh keep up the good work developers :)

    but just one more thing am I the only person who can’t download lyrics and album artworks through GST or am i supposed not to?

  5. I don’t think it’s the right choice to discontinue work on GST.

    Whatever software we develop, we usually develop it for some platform or for a certain runtime context. Hence, it’s never entirely in our hands whether our app still runs on version X+n of the platform/runtime. That’s why users of our software usually have to accept terms & conditions before they the get a chance to use it.

    So, a sandboxed iTunes might break GST in n months or years?
    Fine, you’ll have to ship an update.
    Lion upgrade 10.7.X brings a new entitlement scheme or different sandbox conditions?
    Fine, you’ll have to ship an update.

    Are you afraid that iTunes gets so sandboxed at one point that software like GST has no chance of interacting with it? Even considering Apple’s track record in this respect I heavily doubt this is going to happen. Way too much software has been built around iTunes over the last few years.

    I’m sure a large majority of your user base would happily accept these circumstances in order to get GST back – I’d accept it in an instant. Things change, OSs get updated, apps stop working, that’s life.

  6. For the price of this product and its service, I would be willing to deal with the potential unstable scenarios. I mean, I’d be ok if you release what you have until now and let the customer get an update later on, and if we have to pay for it again so be it. The work you do is great and worth to deal of this, after all, you are not a global conglomerate that we as a customer can come after, I understand Apple stands behind of some part of what you do, which is also good, but as I said for the price, it’s totally worth. By the way, I’ve been enjoying GMST for about 3 years now even with it’s recent shortcomings.
    Thanks and hope you keep it up!!

  7. If we always worried about our software being usable with unchanged code, look and feel or functionality, there would be no software written. If Apple knew a permanent solution to “temporary exceptions”, why would they release them in the first place? By the time they are through sandboxing Final Cut Pro, Xcode and the rest of their own app store stuff, they will probably either a. have a solution that works for your or b. put the idea in the same bin as resolution independence. Of course, big companies do screw up and Apple HAS screwed up many times. But right at the moment their app store has more pros than cons for developers and users alike. If it doesn’t work out in future, you can always go back to selling software on your website like people always have or give a whirl to Windows/Android.

  8. Any word on an update to this situation? So far there is no decent alternative to GimmeSomeTune, and was hoping a couple of months would have seen a resolution.

    Cheers

    Jamie

  9. another voice in the wilderness asking for a GST update! there is nothing else so slimline and fully featured! please help us!

  10. I appreciate your article, but “brake” is what you step on to slow down your car. “Break” causes something to become broken.

  11. While I’m waiting on the next version of GimmeSomeTune, I’m using TunesArt. Does pretty much everything.

  12. Hi,

    You say “so the user could make Preview.app work again”; could you explain how to do that?

    Steffen

  13. Steffen,

    Navigate to /Users/yourname/Library/Application Support/PresentYourApps in Finder.
    If you can’t find the Library folder, open a finder window, hold down the option key on your keyboard and click on “Go To”, there should be an entry called Library – select it.

    In the PresentYourApps Folder inside the Application Support folder, there should be another folder called Preview. Inside that folder you’ll find all the backuped files. Info.plist should be one of them. This file is the one PresentYourApps changes. Before you do anything else, please make another copy of that file somewhere safe.

    After you’ve made a backup copy, please proceed as follows:
    Navigate to /Applications in Finder and right-click (control-click) onto Preview and select “Show Package Contents”. A new finder window appears. select Contents. Replace the Info.plist file in that Contents folder with the backuped one from the Application Support folder. Try launching Preview again.

    If none of this applies to you, please mail me at support@eternalstorms.at

Comments are closed.