This is a quest to learn about the ‘Entitlements’ which are new on the Mac with OS 10.7 and are somewhat like iOS stuff.
Android has some vaguely similar stuff too.
At least Apple was honest enough not to call them capabilities.
There are some Unix options called ‘capabilities’ which are not.
Perhaps this is Apple’s introduction.
This blog provides some opinions and good information.
The author knows more about OS X than I but less about capabilities.
Some of his criticism would be countered by more optional entitlements.
The gist of the design is that the application programmer goes to extra work to let the sandbox mechanism help enforce the policies that the programmer already intended, or at least claims to have intended.
This is a very good goal.
Also, because the existence of your signature is proof of authenticity, Mac OS X can treat updated versions of the application exactly as it treated the previous versions, so users are not bothered with dialogs asking for permission to access the keychain or similar resources (if the application was signed by the same key.)
Well that is a fairly good rule but there are serious drawbacks.
I may have been honest and reliable when I shipped software to you, but I may have now a new business plan of which you may not approve.
I may have been turned or blackmailed.
Code signing and entitlements both have their place but they are very different places.
While it should often be desirable to do both, either tends to alleviate the need for the other.
You may be aware of the sandboxing functionality that existed in previous versions of Mac OS X.
Because the full sandbox profile language is extremely complex (and because the sandboxing requirements of the various frameworks are also complex), raw sandbox profiles are not considered public API.
Instead, Mac OS X provides these higher-level entitlements built on top of those sandbox profiles to provide common classes of functionality.
This sounds like security thru obscurity which is not good!
I would also like to see tools to help the user or corporate system administrator explore what apps can do what.
Here is a list of named entitlements.
I am dubious that they all begin “com.apple.security … ”, as they all belong to Apple.
Note in particular “com.apple.security.files.user-selected.read-only” which lets the app read a file subject to the user’s interactive permission that is specific to the file.
I found the .plist for Apple’s TextEdit here:
Perhaps the command:
is a beginning.
On my machine that shows only:
Perhaps those are the only apps from Apple that have been contained so far.
Property lists are critical to all this.
Command plutil in this context is too.
cp /Users/norm/Library/Containers/com.apple.Preview/Container.plist TE.plist
plutil -convert xml1 TE.plist
I see in the converted file TE.plist:
“SandboxProfileDataValidationInfo” followed my a list of entitlement names each paired with “<true/>”.
A bit of a surprise is “com.apple.security.camera” which I would not expect preview to have.
Access by an application to its files
There are two absolutely vital features, the lack of which prevent this from being a capability system:
See this elaboration.
At least Apple has the honesty not to call entitlements ‘capabilities’.
- Capabilities can be passed like parameters, a bit like file descriptors can be passed thru pipes in Linux.
Without this it is like trying to do software while limiting subroutine depth to two.
(“com.apple.security.inherit” is a partial workaround but much too limited a solution.)
- New capabilities can be defined in user mode code, itself subject to capability discipline.
Entitlements can be invented only by Apple and code that defines those entitlements is all powerful.
Without this feature we sill soon have a gigabyte of code in the TCB.