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 entitlementcom.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:
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.
# Get permissionsplutil-convertxml1.com.apple.containermanagerd.metadata.plist-o-# Binary sandbox profile<key>SandboxProfileData</key><data>AAAhAboBAAAAAAgAAABZAO4B5AHjBMkEQAUPBSsGPwsgASABHgEgASABHwEf...# In this file you can find the entitlements:<key>Entitlements</key><dict><key>com.apple.MobileAsset.PhishingImageClassifier2</key><true/><key>com.apple.accounts.appleaccount.fullaccess</key><true/><key>com.apple.appattest.spi</key><true/><key>keychain-access-groups</key><array><string>6N38VWS5BX.ru.keepcoder.Telegram</string><string>6N38VWS5BX.ru.keepcoder.TelegramShare</string></array>[...]# Some parameters<key>Parameters</key><dict><key>_HOME</key><string>/Users/username</string><key>_UID</key><string>501</string><key>_USER</key><string>username</string>[...]# The paths it can access<key>RedirectablePaths</key><array><string>/Users/username/Downloads</string><string>/Users/username/Documents</string><string>/Users/username/Library/Calendars</string><string>/Users/username/Desktop</string><key>RedirectedPaths</key><array/>[...]
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:
(version 1) ; First you get the version(deny default) ; Then you shuold indicate the default action when no rule applies(allow network*) ; You can use wildcards and allow everything(allow file-read* ; You can specify where to apply the rule (subpath "/Users/username/") (literal "/tmp/afile") (regex #"^/private/etc/.*"))(allow mach-lookup (global-name "com.apple.analyticsd"))
Check this researchto 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:
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:
(version 1)(deny default)(allow file* (literal "/private/tmp/hacktricks.txt"))(allow process* (literal "/usr/bin/touch"))(allow file-read-data (literal "/")); This one will work
Note that the Apple-authoredsoftware that runs on Windowsdoesn’t have additional security precautions, such as application sandboxing.
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:
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:
sbtool<pid>mach#Check mac-ports (got from launchd with an api)sbtool<pid>file/tmp#Check file accesssbtool<pid>inspect#Gives you an explaination of the sandbox profilesbtool<pid>all
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: