Skip to main content
nono uses Apple’s Seatbelt sandbox framework on macOS to enforce capability restrictions at the kernel level.

What is Seatbelt?

Seatbelt is macOS’s mandatory access control (MAC) framework. It’s the same technology that sandboxes App Store applications and Safari. Seatbelt policies are enforced by the XNU kernel - they cannot be bypassed by userspace code.
Note: nono uses Apple’s private sandbox_init() API rather than the newer sandbox_apply_container(). While technically undocumented, this API has been stable for over a decade and is widely used by third-party tools. Apple’s public sandbox-exec command uses the same underlying mechanism.

How nono Uses Seatbelt

nono generates a Seatbelt profile (a Scheme-like DSL) based on your capability flags, then calls sandbox_init() to apply it before executing the target command.

Profile Structure

A nono-generated Seatbelt profile follows this structure:

Security Model: “Allow Discovery, Deny Content”

nono uses a nuanced approach to sensitive path protection: This approach:
  • Prevents data exfiltration - actual file contents cannot be read
  • Allows graceful error handling - programs can check if files exist without crashing
  • Mirrors TCC behavior - feels native to macOS users

System Paths

nono allows read access to system paths required for running executables. These are loaded from security-lists.toml: The file-map-executable permission is also granted globally, which is required for dyld to map executables and shared libraries into memory.

Sensitive Paths

nono explicitly denies data access to credential storage: Users can override these with explicit --allow or --read flags.

System Operations

nono narrows system* permissions to only what’s commonly needed: Notably omitted: system-audit, system-privilege, system-reboot, system-set-time

Network Control

Network access is allowed by default:

Unix Socket Connections

When a process calls connect(2) on a Unix socket (e.g., /var/run/docker.sock), Seatbelt classifies the operation as network-outbound, not a file operation. This means a file-read-data or file-write-data deny rule for the socket path will not block the connection. To block Unix socket connections, nono emits an additional rule alongside the standard file deny rules when a socket path appears in add_deny_access:
The network-outbound rule uses (path ...) for an exact match rather than (subpath ...) because socket connections match on the precise path. Seatbelt evaluates this rule at connect(2) time, so it blocks connections to sockets that do not exist when the sandbox initializes.

Granular Filtering Limitations

Seatbelt supports filtering by protocol (TCP/UDP), direction (inbound/outbound), and even IP address via remote ip filters. However, it does not provide per-hostname or per-domain filtering. Since DNS resolution happens before the connection, filtering by domain would require:
  1. IP allowlists - Fragile due to CDNs, load balancers, and changing IP addresses
  2. Application-layer proxy - Adds complexity, requires elevated permissions
  3. Packet filtering (pf) - Requires root, conflicts with nono’s design
For now, nono uses binary network control (all or nothing). Granular filtering may be explored in future releases.

Irreversibility

Once sandbox_init() is called, restrictions are permanent:
  • There is no sandbox_remove() or sandbox_expand() API
  • The process cannot modify its own sandbox
  • All child processes inherit the restrictions
  • The only way to escape is to exploit a kernel vulnerability
This is the core security guarantee.

Debugging

If a command fails with permission errors:
  1. Run with --dry-run to see what capabilities would be granted
  2. Run with -vvv for verbose logging (shows generated profile)
  3. Check Console.app for sandbox violation logs:
    • Filter by “sandbox” or your process name
    • Violations show the exact path and operation blocked

Common Issues

Limitations

macOS Version Support

Seatbelt is available on macOS 10.5+, but nono is tested on macOS 10.15 (Catalina) and later. macOS 10.15+ uses APFS with firmlinks - bidirectional hard links that make /System/Volumes/Data/Users appear as /Users. nono’s security lists include /System/Volumes to handle path resolution across firmlink boundaries. Without this, sandbox rules written for /Users/luke might not match the kernel’s resolved path /System/Volumes/Data/Users/luke.

TCC Interaction

macOS TCC (Transparency, Consent, and Control) may still block access to certain paths if the terminal running nono doesn’t have “Full Disk Access.” nono’s “Allow Discovery, Deny Content” approach mirrors TCC behavior.

App Sandbox Interaction

If nono runs inside an App Sandbox (e.g., from a sandboxed terminal), restrictions stack. The inner sandbox cannot grant more permissions than the outer sandbox allows.

Code Signing

Some macOS security features interact with code signing. Building nono from source without signing may trigger Gatekeeper warnings, but this doesn’t affect sandbox enforcement.

References