Next post Previous post

The App Store, sandboxing, and AppleScript

August 3, 2011 at 11:24 AM by Dr. Drang

When I read the Security section of John Siracusa’s Lion review at Ars Technica, I got a little nervous. Here’s what he says about sandboxing and the new behavior that will be forced on applications that want to be sold in the Mac App Store starting this November:

In Lion, the sandbox security model has been greatly enhanced, and Apple is finally promoting it for use by third-party applications. A sandboxed application must now include a list of “entitlements” describing exactly what resources it needs in order to do its job. Lion supports about 30 different entitlements which range from basic things like the ability to create a network connection or to listen for incoming network connections (two separate entitlements) to sophisticated tasks like capturing video or still images from a built-in camera.

It might seem like any nontrivial document-based Mac application will, at the very least, need to declare an entitlement that will allow it to both read from and write to any directory owned by the current user. After all, how else would the user open and save documents? And if that’s the case, wouldn’t that entirely defeat the purpose of sandboxing?

Apple has chosen to solve this problem by providing heightened permissions to a particular class of actions: those explicitly initiated by the user. Lion includes a trusted daemon process called Powerbox (pboxd) whose job is to present and control open/save dialog boxes on behalf of sandboxed applications. After the user selects a file or directory into which a file should be saved, Powerbox pokes a hole in the application sandbox that allows it to perform the specific action.

He said basically the same thing on the most recent Hypercritical episode. The part that worries me is the restriction on elementary things like reading and writing to files. If these are only allowed when “explicitly initiated by the user” how can AppleScripts work? An AppleScript that reads and writes files isn’t doing so under the explicit action of the user, it’s doing it under the control of a script, which seems to be exactly the sort of thing sandboxing is designed to control.

Maybe, I thought, if the user launches the AppleScript that would count as “initiated by the user.” Still seems like a vector for the kind of mischief Apple wants to quash.

Clark Goble of Clark’s Tech Blog wrote a post about AppleScript and sandboxing that showed he was nervous about Apple’s commitment to AppleScript, too.1 I tweeted a link to Clark’s post, which started a three-part conversation between him, me, and Ivan Krstić (@radian). Here it is, with links to the original tweets if you don’t trust my quoting:

drdrang: Unsurprisingly, @ClarkGoble is also wondering about Lion’s sandboxing and AppleScript: http://xrl.us/bk3kro.

radian: That post is wrong. Sandboxed apps can receive Apple Events by default. Temp. exceptions are only required for sending.

drdrang: Don’t apps like FastScripts and TextExpander need to send Apple Events?

radian: They do, but the post claims you need exceptions to receive. You can receive by default. Exceptions needed for sending.

drdrang: Fair enough. My concern is that if apps that send go away, there’s no reason for apps to receive. The whole AS ecosystem dries up.

ClarkGoble: The problem is the general case of sending AppleEvents.

ClarkGoble: The post doesn’t say you need exceptions to receive. I had thought you had to set the entitlement though to receive.

ClarkGoble: Reading through guide it looks like you don’t. http://goo.gl/o6mLk

Clark has fixed the mistake Ivan was talking about, but I think his main point stands: Apple’s new requirements for getting into the Mac App Store are going to make AppleScripting less attractive.

Sandboxing will be handled through entitlements, which are described in this developer guide. Briefly, every app that wants to be in the Mac App Store will have to request specific entitlements to be allowed to do things like read and write files, open network connections, access the camera, and so on. The full list is given in the aforelinked guide. As part of the vetting process, Apple will assess the request for entitlements and will give a thumbs-up or thumbs-down depending on whether the request matches the real needs of the application.

The ability to send Apple Events is in the entitlement area is called temporary exceptions, which, I confess, sounds a little mysterious to me. I’m not sure what the word temporary refers to. Clark seems to think it means these are actions Apple is allowing now but may shut down, or substantially change, in the future.

In any event,2 here’s what Apple says about this exception:

Send Apple events—The ability to send Apple events to the specified destination application.

So it looks like your application will be allowed to send Apple Events,3 but it will have to specify the destination app. It’s not clear from this language if you’ll be allowed to send Apple Events to more than one app, but if you are, you’ll certainly need to request an exception for each app.

Which sounds like a big problem for applications like FastScripts and TextExpander, because these programs need to work with any and all apps.

I suppose Daniel Jalkut could argue that FastScripts itself doesn’t send Apple Events, it just launches AppleScripts written in and packaged by Apple’s own AppleScript Editor. Given the problems he’s had getting FastScripts into the store—rejected because it won’t run a buggy Apple-supplied script that fails in Lion—I suspect that argument won’t fly.

The folks at Smile have no such argument. TextExpander’s AppleScript snippets don’t run code written and packaged elsewhere; you put the source code directly in TextExpander and it runs it when called. TextExpander has no way of knowing ahead of time which applications it will be sending Apple Events to. The only possible answer to that question is “all of them.” I don’t see how this is compatible with Apple’s sandboxing rules.

Now, TextExpander is already in the Mac App Store, so maybe all these sandboxing issues have been worked out and my worries are unfounded. If that’s the case, I’d like to hear someone from Smile weigh in and explain it. Because I’ve written quite a few AppleScript snippets, and I don’t want to see them sandboxed out of existence.

  1. I should mention here that AppleScript itself—a language I despise—isn’t the issue. It’s the Apple Events system of message passing that Clark and I are worried about. AppleScript is certainly the most common way to send and receive Apple Events, but it’s not the only one. Both Python and Ruby can handle Apple Events through the Appscript library. ↩

  2. I slay me. ↩

  3. I pretty sure Apple used to capitalize the word events, a style choice that made more sense than the current lowercase. I’m sticking with the old style. ↩

Next post Previous post