Note: For more information about the information contained in this article, contact us for a professional consultation.
In our previous tech journal article, we touched on the history of sandboxing, from its evolution out of the POSIX model to the more granular controls provided by the ACL model and how they are both derived from a concept called Discretionary Access Controls. For this discussion, please check out out previous article “A brief introduction to Mac OS X SandBox Technology.”
New Sandboxing & Privilege Separation in Lion
This article will attempt to clarify and explain the changes in Lion and iOS sandboxing and the upcoming change in requirements for App Store submissions. Apple has decreed that all applications submitted to the App Store MUST be sandboxed, originally the deadline was November 2011, but the deadline has recently been moved back to March 1, 2012.
iOS sandboxing has been in place for a while now. iOS applications can only see their own data and documents, cannot alter your devices underlying settings, and generally appear to be isolated from other apps on your iOS device. Apple has brought this methodology to Macs with 10.7 Lion.
Compared to previous Mac OS security models, Lion has made leaps and bounds in terms of sandbox security, with Apple finally promoting the technology for use by third party developers. The 2 ways of Apple has increased security is through Sandboxing and Privilege Separation. Sandboxing refers to the process whereby a developer specifies a list of expected operations an application will perform, while Privilege Separation refers to splitting an application or daemon into more granular pieces where each piece is only given rights to its particular task. Every sandbox application must include a set of “entitlements,” or a list of resources the application needs to perform its tasks. Lion has around 30 entitlements ranging from low-level operations (e.g. creating or listening to network connections), to higher level operations (e.g. printing or accessing the camera).
Application Sandboxing
App Sandboxing can help prevent flaws or oversights in programming from becoming security threats via privilege escalation. By specifying a set of entitlements, a developer tells the OS which operations are allowed and expected. This way if a user process tries to perform a task that is not entitled, the OS will not allow the task. This makes executing arbitrary code from a problem like a buffer overflow much less likely. Listing entitlements also lets the system know to create a container directory for the application itself and runs it inside a sandbox configured for that particular application. If a developer creates an internet browser application and didn’t grant the entitlements to the camera and microphone, a website with malicious code trying to access the camera would be thwarted by the OS.
The container directory is where your sandboxed application can read and write its private files and data, including preferences, autosave info and other information needed by the application itself. The sandboxed application is prevented from accessing data and files from outside the sandbox with a few exceptions, like the systems Open and Save dialog boxes, which require user intervention to explicitly work outside the sandbox. Upon first launch, the OS creates a container directory in ~/Library/Containers with the application bundle identifier as the directory name (e.g. com.apple.TextEdit).
Sandboxing an application is not a replacement for good coding practices or testing. Indeed, sandboxing actually will increase the requirements for testing as each entitlement will need to be verified and tested, but it will provide a valuable line of defense against unanticipated malware or other nefarious activity.
App Store Sandboxing
While not being privy to behind the scenes discussions at Apple, the benefits of requiring Application sandboxing for App Store submissions are fairly intuitive. By requiring sandboxing, Apple will simplify its audit process and can more easily provide security assurances for App Store purchases. Ars Technica seems to confirm this as well. By sandboxing all Apps, Apple will greatly reduce the potential for rogue code coming out of the App Store, thereby reducing their potential liability.
Adding Sandboxing to your applications in Xcode
To sandbox an application in Xcode, you will need a couple of things. One is a valid code signing certificate issued by a trusted third certification authority (think Verisign, Thawt or Digicert). Self-signed certificates won’t work as your Certificate Authority (CA) credentials are not included in either the Mac OS or iOS. The CA root certificate allows a chain of trust to be built to your code signing certificate. Apple has more info on their Root Certificate program here.
An entitlements .plist, named Info.plist. You will add this file in your project in Xcode. The Info.plist must have the following Keys: CFBundleIndentifier, CFBundleName. The identifier MUST be globally unique. To help ensure this, please include your company’s name in the indentifier (e.g. com.318.OurLatestApp). Apple recommends that the identifer be in reverse DNS notation as well. Your Info.plist must include all the entitlements your application needs.
In Xcode, please add the following linker flags:
-sectcreate __TEXT __info_plist Info.plist_path
where Info.plist_path is the complete path of the Info.plist file in your project.
These flags should be added to the OTHER_LDFLAGS build variable in Xcode. Please refer to the documentation for other development environments.
You will also need to go into the summary tab for your Xcode project and check
- Enable Entitlements
- Enable App Sandboxing
A comprehensive guide to code signing and entitlements is available from Apple here.
Wrapup
Apple’s new paradigm for security will provide additional protection from malicious code. This new paradigm will necessitate some additional planning and testing. It will allow Apple to better ensure that any App from the App Store will not harm your computing experience. Apple has a list of entitlements that must be used, but you must be a developer to access this content. In the writing of this article we have attempted to be cognizant of what is and is not under non-disclosure, so if you need access to that, then please grab a free account at the Apple Developer Connection.
