macOS Sandbox
Basic Information
MacOS Sandbox (initially called Seatbelt) limits applications running inside the sandbox to the allowed actions specified in the Sandbox profile the app is running with. This helps to ensure that the application will be accessing only expected resources.
Any app with the entitlement com.apple.security.app-sandbox
will be executed inside the sandbox. Apple binaries are usually executed inside a Sandbox and in order to publish inside the App Store, this entitlement is mandatory. So most applications will be executed inside the sandbox.
In order to control what a process can or cannot do the Sandbox has hooks in all syscalls across the kernel. Depending on the entitlements of the app the Sandbox will allow certain actions.
Some important components of the Sandbox are:
The kernel extension
/System/Library/Extensions/Sandbox.kext
The private framework
/System/Library/PrivateFrameworks/AppSandbox.framework
A daemon running in userland
/usr/libexec/sandboxd
The containers
~/Library/Containers
Inside the containers folder you can find a folder for each app executed sandboxed with the name of the bundle id:
Inside each bundle id folder you can find the plist and the Data directory of the App:
Note that even if the symlinks are there to "escape" from the Sandbox and access other folders, the App still needs to have permissions to access them. These permissions are inside the .plist
.
Everything created/modified by a Sandboxed application will get the quarantine attribute. This will prevent a sandbox space by triggering Gatekeeper if the sandbox app tries to execute something with open
.
Sandbox Profiles
The Sandbox profiles are configuration files that indicate what is going to be allowed/forbidden in that Sandbox. It uses the Sandbox Profile Language (SBPL), which uses the Scheme programming language.
Here you can find an example:
Check this research to check more actions that could be allowed or denied.
Important system services also run inside their own custom sandbox such as the mdnsresponder
service. You can view these custom sandbox profiles inside:
/usr/share/sandbox
/System/Library/Sandbox/Profiles
Other sandbox profiles can be checked in https://github.com/s7ephen/OSX-Sandbox--Seatbelt--Profiles.
App Store apps use the profile /System/Library/Sandbox/Profiles/application.sb
. You can check in this profile how entitlements such as com.apple.security.network.server
allows a process to use the network.
SIP is a Sandbox profile called platform_profile in /System/Library/Sandbox/rootless.conf
Sandbox Profile Examples
To start an application with an specific sandbox profile you can use:
Note that the Apple-authored software that runs on Windows doesn’t have additional security precautions, such as application sandboxing.
Bypasses examples:
https://desi-jarvis.medium.com/office365-macos-sandbox-escape-fcce4fa4123c (they are able to write files outside the sandbox whose name starts with
~$
).
MacOS Sandbox Profiles
macOS stores system sandbox profiles in two locations: /usr/share/sandbox/ and /System/Library/Sandbox/Profiles.
And if a third-party application carry the com.apple.security.app-sandbox entitlement, the system applies the /System/Library/Sandbox/Profiles/application.sb profile to that process.
iOS Sandbox Profile
The default profile is called container and we don't have the SBPL text representation. In memory, this sandbox is represented as Allow/Deny binary tree for each permissions from the sandbox.
Debug & Bypass Sandbox
On macOS, unlike iOS where processes are sandboxed from the start by the kernel, processes must opt-in to the sandbox themselves. This means on macOS, a process is not restricted by the sandbox until it actively decides to enter it.
Processes are automatically Sandboxed from userland when they start if they have the entitlement: com.apple.security.app-sandbox
. For a detailed explanation of this process check:
Check PID Privileges
According to this, the sandbox_check
(it's a __mac_syscall
), can check if an operation is allowed or not by the sandbox in a certain PID.
The tool sbtool can check if a PID can perform a certain action:
Custom SBPL in App Store apps
It could be possible for companies to make their apps run with custom Sandbox profiles (instead of with the default one). They need to use the entitlement com.apple.security.temporary-exception.sbpl
which needs to be authorized by Apple.
It's possible to check the definition of this entitlement in /System/Library/Sandbox/Profiles/application.sb:
This will eval the string after this entitlement as an Sandbox profile.
Last updated