Solipsism Gradient

Rainer Brockerhoff’s blog

Browsing Posts published in February, 2012

I had just published my previous post about Mountain Lion and Gatekeeper when Apple announced the third postponement of the sandboxing deadline for the Mac App Store, this time until June.

This was expected; given the announcements and the changes in the sandbox details (including some unannounced ones which I can’t comment on), a postponement was inevitable. In fact, my hunch is that at WWDC 2012 a final postponement will be announced, to coincide with the golden master of 10.8; or, at the very least, 10.7.4 will be back-fitted with the same Gatekeeper and sandboxing capabilities. This latter option has a potential pitfall; Xcode doesn’t like applications setting their minimum system version to a point release.

A brief recap of the sandbox is in order. If the developer turns on sandboxing, the application will run inside a protected environment. The user’s home folder is substituted by a per-application container where parts of the original home are reflected by symbolic links. Certain folders, such as ~/Library and ~/Documents, are not reflected. A sandboxed application’s system calls are closely monitored and restricted. The intention is that the application cannot interact with other applications, or with other app’s documents – not even with their preferences. However, some parts of the file system can always be read, basically to allow the application to use system resources.

These restrictions can be selectively eased either by a signaled user intention or by a list of so-called “entitlements” set into the application signature. Entitlements can allow access to iCloud, to selected hardware such as networks, cameras or printers, to user databases such as calendar or address book, or to parts of the file system outside of the application container such as music, picture or movie folders. Access to files can be granted as read-only or read-write.

User intentions can be signaled by actions such as dragging & dropping icons from the Finder onto the application’s icon or windows, or by selecting files/folders from the standard open or save panels (and there are entitlements for that option). This opens a temporary breach in the sandbox for that run; starting with 10.7.3, this access permission can be stored into a bookmark file for later use by the application.

Temporary exemptions can be granted to allow the application permanent access to any part of the file system, however Apple advises that such exemptions may not be allowed for apps in the Mac App Store.

Many other actions are restricted by design, and there are no entitlements to allow sandboxed apps to send AppleEvents to other apps, to use the Accessibility APIs for controlling other applications, and so forth. Add that to other restrictions already in place for the Mac App Store – such as not allowing privilege escalation by asking for an administrator password, system preference panels, etc. – and it’s understandable that developers are viewing the forthcoming sandbox requirement with trepidation and even anger.

On the other hand, for the user, sandboxing has its advantages. Losing data by program bugs or malicious code is restricted to the few places where read-write access is granted. Applications that “phone home” won’t be able to do so unless network access is allowed by an entitlement. If the entitlements are carefully chosen and restricted to the exact functionality of the app, everything should be well.

Unfortunately, the current entitlements are relatively few and more related to Apple’s initial ideas about what type of app should be on the Mac App Store – a game or relatively simple document-based application, perhaps. Now that Gatekeeper will be allowing “identified developers” to sign applications, Apple should also encourage these developers to use the sandbox. Well-known developer Daniel Jalkut says that the sandbox should be expanded:

Apple should embrace the utility of sandboxing by shifting their focus away from sandboxing only Mac App Store titles, to a strategy that would sandbox virtually every Mac app, inside the store or out…

To increase adoption, Apple should expand the current list of entitlements until it covers every reasonable behavior that users expect from Mac apps…

Finally, Apple should take a cue from its own Gatekeeper approach. By incorporating sandbox information about apps into the forthcoming app security preference pane, they will empower users to understand application intentions.

I agree fully with Daniel but would like to expand his proposal even more. We need more fine-grained entitlements that also encompass things that are currently done by older methods. For instance, to interact with other apps over the Accessibility APIs, application’s binaries need to be blessed with the old Unix setgid bit – or the user has to be oriented to allow all and any applications to do this. This would be easily solved by a specific entitlement. No doubt some entitlements might be restricted to administrator-level users. All in all, expanded entitlements will be in the general interest.

All that’s missing is an easy way of communicating to the user what entitlements the sandboxed application has set into its signature. Rather than do this in the security preference pane, I’d like to renew the idea I mentioned in my previous post: an information panel that’s shown on the first run for a signed application (and easily found by the user for re-checking thereafter). Besides showing information about the code signature and the authoring developer, this panel should also show a concise explanation of the entitlements requested by the application; with that information, the user can fully decide whether running that app will be worthwhile. Hm, why does this game want access to my Address Book, to the Internet, and read/write access to my entire hard drive? Looks suspicious…

This would take care of applications signed by identified developers. Unsigned applications that run without a sandbox should rightly be viewed with some suspicion. I don’t see many arguments in favor of anonymously-authored applications, but in any case, with the upcoming model, the user always has the option to make exceptions.

There remains great controversy about what was, until a few days ago, the main use for the sandbox: in Mac App Store applications. There was no incentive for non-MAS apps to be sandboxed, and Apple seemed to be unyielding in expanding the available entitlements – the gist on the developer forums seemed to be “either fit in the sandbox as it is or don’t sell over the MAS”. There are temporary exceptions and some (very few) developers got personal workarounds, but it all feels very constraining. In my opinion, it’s extremely worthwhile for developers to file feature requests for the sandbox outside the MAS. After all, it’s in Apple’s own interest to see wider sandbox adoption, and the hope is that some of those new entitlements will – after some time – flow back to benefit MAS apps.

Who knows, perhaps Apple will, in time, allow identified developers to sell iOS apps outside the App Store? It all depends on how successful that model is on the Mac. After all, confluence should go both ways!

Update: I just found Uli Kusterer‘s article about the sandbox which makes several of the same points, including one I’d forgotten to mention above: entitlements could easily refer to other applications just by mentioning their bundle ID (and perhaps, distinguishing between sending AppleEvents to that app, accessing their preferences or sandboxed files, and so forth).

New Cat in the Sandbox

No comments

In a surprise move by Apple, Mountain Lion (aka Mac OS X 10.8) was announced early and in an unorthodox manner.

Their new infrastructure seems to be working well – I downloaded and installed the beta very soon after the announcement. It’s working well (for a beta) in a VMware virtual machine after following this hint.

Let me comment briefly on the “iOSification of OS X” question. Having consistent app names (and, to some extent, user interfaces) between similar applications on both iOS and OS X is a good thing. Greater integration with iCloud was also pending, and here too users need a consistent interface on both platforms. Beyond that, there seems to be little evidence that the operating systems themselves will suffer anything but a benign cross-pollination of features and APIs.

As a developer, I’m more interested in what code signing, the upcoming Gatekeeper and sandboxing requirements for the Mac App Store mean for future applications.

Code signing has been a feature of Mac OS X for some time now. The details are tricky but, in essence, executable code can be signed using an “identity” backed by a “trusted” chain of certificates. Such a certificate is a variation of the ones deployed for “trusted” websites – those whose addresses start with “https:”. Obtaining a so-called “self-signed” certificate and signing an application on OS X is quite easy, and several of my applications have been signed in that manner.

On the downside, anyone can strip such a signature and substitute another one; and checking for that is not easy for the user. Here’s part of my current Klicko product page:

To check that Klicko’s signature is intact, open Terminal, paste in the following command, and press the Return key:

codesign -dvvv -r- /Library/PreferencePanes/Klicko.prefPane

(assuming that you installed Klicko for all users; otherwise, type a tilde (~) before the /Library part.) You should see several result lines in the Terminal.Authority=Rainer Brockerhoff should be present, and identify the author. The last line should end with …root = H”4cbb97c74336f7ee6aa566122a5e7688e1c725dc” and uniquely identify the author’s signature. Now run the following command:

codesign -vv /Library/PreferencePanes/Klicko.prefPane

If the Klicko bundle is intact, this should display valid on disk; otherwise you’ll see code or signature modified. In the latter case, throw it into the Trash.

Not something that a non-techie user would do; and the system doesn’t (yet) complain if you try to run an unsigned application (or one whose signature or executable has been tampered with). Even so, on current systems there are benefits to running signed code: parental controls and keychain access are example cases.

Code signing has been mandatory on iOS from the very beginning – it won’t run applications not signed by a registered developer, backed by Apple’s own trusted certificates. The whole “jailbreaking” paradigm stems from that feature: normally, only apps from Apple’s App Store may run, and Apple can revoke an application’s certificates if the application misbehaves.

Enter Gatekeeper. As far as is known, it has three levels, selectable by the user in System Preferences, allowing the user to run applications that come from:
1) the Mac App Store only (same as on iOS devices);
2) from the Mac App Store and identified developers;
3) from anywhere (same as on current and previous systems).
It’s of course unknown which of those levels will be default when 10.8 goes golden.

Gatekeeper is triggered by the well-known “quarantine” attribute set on applications and disk images downloaded from the Internet. After the usual dialog alerting you to that fact, if you’ve set Gatekeeper to level 1 or 2, the application’s signature is checked; if it’s not backed by the corresponding trusted Apple certificate, a further dialog advises you not to run that application. There’s no override option unless you opened the application from the contextual menu (instead of double-clicking). Also note that this doesn’t happen with applications copied from external drives.

Parts of Gatekeeper are already available on 10.7.3 but must be turned on with a Terminal command. The most restricted level isn’t available, and for an improperly signed app the complaining dialog curtly advises you to “move [the app] to the Trash”; it even offers a button to do so. Although this dialog doesn’t seem to occur on 10.8, some developers are considering it a bad sign of things to come.

But it is the intermediate Gatekeeper setting which is the most important; hopefully it will be the default. So what is meant by “identified developers”? Currently, this is someone who paid the annual $99 fee to be part of Apple’s Mac developer program. As I am in that position, I’ve already requested and downloaded my code signing certificate, and will use it to sign my future applications – those published outside the Mac App Store.

The benefits to myself are obvious. Anybody who downloads my applications through the usual channel – directly from my website – can be assured that it is signed by myself, that it hasn’t been tampered with by a third party, that I’m a registered developer, and that Apple certifies that all this is true. Still, some additional care needs to be taken, both by Apple and by the user. Specifically, when 10.8 comes out it should have an easily accessible information window containing the following information: (sorry, no time to make a graphic mockup)

<Application name and version> is signed by <developer name> developer ID number.
<Link to developer/application site>
<List of certificates and their expiration dates>
Apple disclaimer (for non-Mac App Store applications).

This information should be shown on first run – perhaps on request from the “quarantine” dialog – and from somewhere in the Finder. Note also that Apple can revoke a developer’s certificate; it’s as yet unknown if that will affect already-downloaded applications (as I think it does on iOS) or not.

As I said, the user can take steps to run the application even if Gatekeeper advises against it. Unless this option is removed when 10.8 goes out of beta – and it would make no sense at all for Apple to remove it – it’s a welcome step for serious developers. And it’s a practical intermediate solution for applications or system plug-ins that don’t fit into the Mac App Store’s restrictions; specifically, regarding the impending MAS requirement for turning sandboxing on. More on that in my next post.

[Updated to fix an error regarding Gatekeeper on 10.7.3.]

Photos licensed by Creative Commons license. Unless otherwise noted, content © 2002-2017 by Rainer Brockerhoff. Iravan child theme by Rainer Brockerhoff, based on Arjuna-X, a WordPress Theme by SRS Solutions. jQuery UI based on Aristo.