When iOS apps run, they have to operate within a sandbox, sometimes figuratively referred to as Apple’s or the iOS walled garden. At present apps running in OS X are only expected to do so when they are purchased from the App Store, although with macOS Sierra Apple is expected to encourage all app developers to run their apps in a sandbox.
A sandbox restricts an app’s access to operating system resources. In the event that a vulnerability in that app (or which affects the app) is exploited, the sandbox should remain intact, and continue to prevent that app from doing what it shouldn’t.
Consider an app which only reads PDF files, and cannot write to them. In its sandbox profile, it will tell OS X that it needs to be able to open files to read, but not to write them. If a hacker then discovered a vulnerability in that app which they tried to use to encrypt those files and save them, OS X would not allow the app to write those files, because its sandbox profile does not permit it to write files.
If an app does not run in a sandbox, there is no built-in system to prevent it from doing anything that the user who runs the app can do. So when run by an admin user, a hijacked app could encrypt all that user’s documents, and run rife through many very sensitive folders. Given a quick authentication dialog, it could also do nasty things to even more important files, although SIP now prevents it from touching key system files.
The sandbox mechanism is operated for the kernel by a kernel extension named Sandbox.kext in /System/Library/Extensions, which provides the
sandboxd daemon and its support. An app’s sandbox profile is delivered within the app itself, and those for OS X components are kept in /System/Library/Sandbox/Profiles and /usr/share/sandbox.
Common features which can be restricted by a sandbox profile include:
- networking to connect to other systems
- networking to receive incoming connections
- read-only or read-write access to files selected by the user in an Open or Save dialog
- read-only or read-write access to files in standard locations such as ~/Music
- access to Bluetooth, USB devices, and other hardware
- access to contents of the user’s calendars and other data
- access to printing services.
There are two checks to see whether an app runs in a sandbox: first, look in ~/Library/Containers/ to see if that app has a container folder there, containing the resources such as the preference file which it uses. If it does, then it runs within a sandbox.
The other thing that you can do is inspect it using Activity Monitor, when the app is running. Using Activity Monitor’s View menu, enable the Sandbox item in the Columns command. This adds another column which tells you whether each process is running in a sandbox.
Apps which run in a sandbox still have access to the folders and files inside their own container, stored in ~/Library/Containers/. In OS X, apps are not intended to use their container to store user documents. The iOS sandbox system is here both different and far more restrictive: under iOS, the container holds the app itself and all its documents too.
OS X matches sandboxed apps to their containers not by normal identifiers, but by the app’s code signature. This ensures that only correctly-signed versions of an app can access the contents of their own container: another valuable security measure. Apps which run in a sandbox must also be properly signed.
Although the app’s Open and Save dialogs appear similar, regardless of whether the app runs in a sandbox, sandboxed apps actually use a more tightly-controlled version which Apple terms the PowerBox, which cannot be manipulated by malware, for example.
The sandbox system is not new: originally introduced as Seatbelt in OS X 10.5 Leopard in 2007, it developed into a full-blown Sandbox with OS X 10.7 Lion in 2011.