Sunday, September 23, 2012
I've complained that sandboxing was not ready to be mandated for all Mac App Store apps before, and pointed out that Apple seemed to know this as they had not sandboxed any of their own apps. Well, the recent updates to iPhoto and Aperture are actually sandboxed. At first glance, this seems like evidence that sandboxing has passed a huge milestone. Now sandboxing is capable of handling very complete applications such as these. Sadly, that's not exactly the case.
Michael Tsai dug into the entitlements Aperture is using, and found some alarming things. I'll group these into 3 categories.
The most obvious of these is this one:
Yes, that says that it can read and write all files on the system. This is obviously a large access, but I actually have very little problem with them requesting this. I don't mind it because any 3rd party developer could do the same. Of course, they'd have to make their case to the app reviewer as to why they need this access, but it's a publicly available entitlement that anyone could use. They should work to remove this access, but as a temporary stop-gap until system functionality is fixed it's fine by me.
There are three entitlements listed that are not public. These are:
com.apple.security.library-repair.extensions com.apple.security.library-repair.ostype com.apple.security.temporary-exception.sbpl
It doesn't surprise me that Apple is using private entitlements for their own stuff. I'm not sure what the first two do, but they seem to be specifically created to handle their own apps controlling their internal databases. The third is very different, which I'll discuss next.
The sbpl exception, which Daniel Jalkut wrote about, allows them to drop down to the underlying sandbox policy language and allow whatever they like. This is equivalent to inline assembly, and is a way of Apple admitting that the entitlements mechanism is not complete enough to handle this app. In this particular instance, they grant themselves three abilities beyond what is available via normal entitlements:
(allow file-search) (allow ipc-posix-sem) (allow system-fsctl)
The first of these seems odd, as it seems unnecessary given the broad filesystem access they've already granted themselves via temporary entitlements. The second shows one of the many interprocess communication mechanisms that doesn't work fully with sandboxing entitlements - POSIX semaphores. I'm not sure what the third is for, as fsctl can be a catchall for filesystem controls.
Regardless, the point here is that even with incredibly broad entitlements and private entitlements, they still couldn't sandbox Aperture. They had to use this escape hatch to grant additional capabilities outside of entitlements. 3rd party developers can't use this escape hatch.
A bright spot
None of the above is surprising. Many developers have known how much was missing from the available entitlements, so we all knew Apple wouldn't be able to sandbox their apps without cheating. However, there is one surprising and awesome thing in the entitlements. It's this:
<key>com.apple.security.temporary-exception.mach-lookup.global-name:before:10.8</key> <array> <string>com.apple.AOSNotification-FMM</string> </array>
The cool part is at the end of the entitlement. It ends with a suffix indicating this entitlement should only be applied before Mac OS X 10.8. It looks like Apple has heard our cries and added a mechanism for continuing to use temporary entitlements in older OS versions while removing them in newer ones. This is very important for evolving beyond excessive temporary entitlements. It means an app can claim an excessive entitlement (such as the one for all files at the top of this post) only on the older OS versions that contain bugs requiring such excessive access.
This is not yet public, but I really hope it becomes public. Pear Note requires some excessive sandboxing entitlements on Lion, but I don't want to claim those excessive entitlements forever. This mechanism looks like the perfect solution.