Generates minimal macOS Seatbelt sandbox configurations. Use when sandboxing, isolating, or restricting macOS applications with allowlist-based profiles.
Installs just this skill. Get the whole plugin for auto-invocation.
⚡ How it fires
How this skill gets triggered: by you, by Claude, or both.
Fires itselfClaude auto-loads it when your prompt matches the work.
You can call itInvoke it directly when you want it.
Slash command/seatbelt-sandboxer
👁️ Context preview
The summary Claude sees to decide when to auto-load this skill.
Generates minimal macOS Seatbelt sandbox configurations. Use when sandboxing, isolating, or restricting macOS applications with allowlist-based profiles.
📊 Stats
Stars6,229
Forks540
LanguagePython
LicenseCC-BY-SA-4.0
📦 Ships with trailofbits-skills
</> SKILL.md
seatbelt-sandboxer.SKILL.md
---name: seatbelt-sandboxer
description: "Generates minimal macOS Seatbelt sandbox configurations. Use when sandboxing, isolating, or restricting macOS applications with allowlist-based profiles."
allowed-tools: Read Write Bash Glob Grep
---# macOS Seatbelt Sandbox Profiling
Generate minimally-permissioned allowlist-based Seatbelt sandbox configurations for applications.
## When to Use
- User asks to "sandbox", "isolate", or "restrict" an application on macOS
- Sandboxing any macOS process that needs restricted file/network access
- Creating defense-in-depth isolation if supply chain attacks are a concern
## When NOT to Use
- Linux containers (use seccomp-bpf, AppArmor, or namespaces instead)
- Windows applications
- Applications that legitimately need broad system access
- Quick one-off scripts where sandboxing overhead isn't justified
## Profiling Methodology
### Step 1: Identify Application Requirements
Determine what the application needs across these resource categories:
| Category | Operations | Common Use Cases |
|----------|------------|------------------|
| **File Read** | `file-read-data`, `file-read-metadata`, `file-read-xattr`, `file-test-existence`, `file-map-executable` | Reading source files, configs, libraries |
For each category, determine: **Needed?** and **Specific scope** (paths, services, etc.)
If the application has multiple subcommands that perform significantly different operations, such as `build` and `serve` commands for a Javascript bundler like Webpack, do the following:
* Profile the subcommands separately
* Create separate Sandbox configurations for each subcommand
* Create a helper script that acts as a drop-in replacement for the original binary, executing the sandboxed application with the appropriate Seatbelt profile according to the subcommand passed.
### Step 2: Start with Minimal Profile
Begin with deny-all and essential process operations, saved in a suitably-named Seatbelt profile file with the `.sb` extension.
- `file-read*` allows ALL file read operations including from any path
- `file-read-data` only allows reading file contents from listed paths
- Combined with `file-read-metadata` (allowed broadly), this gives:
- ✅ Can stat/readdir anywhere (needed for path resolution)
- ❌ Cannot read contents of files outside allowlist
### Step 4: Add File Write Access (Restricted)
```scheme
(allow file-write*
;; Working directory only
(subpath (param "WORKING_DIR"))
;; Temp directories
(subpath "/private/tmp")
(subpath "/tmp")
(subpath "/private/var/folders")
;; Device files for output
(literal "/dev/null")
(literal "/dev/tty"))
```
### Step 5: Configure Network
Three levels of network access:
```scheme
;; OPTION 1: Block all network (most restrictive - use for build tools)
(deny network*)
;; OPTION 2: Localhost only (use for dev servers, local services)
;; Bind to local ports
(allow network-bind (local tcp "*:*"))
;; Accept inbound connections
(allow network-inbound (local tcp "*:*"))
;; Outbound to localhost + DNS only
(allow network-outbound
(literal "/private/var/run/mDNSResponder") ;; DNS resolution
(remote ip "localhost:*")) ;; localhost only
;; OPTION 3: Allow all network (least restrictive - avoid if possible)
(allow network*)
```
**Network filter syntax:**
- `(local tcp "*:*")` - any local TCP port
- `(local tcp "*:8080")` - specific local port
- `(remote ip "localhost:*")` - outbound to localhost only
- `(remote tcp)` - outbound TCP to any host
- `(literal "/private/var/run/mDNSResponder")` - Unix socket for DNS
### Step 6: Test Iteratively
After you generate or edit the Seatbelt profile, test the functionality of the target application in the sandbox. If anything fails to work, revise the Seatbelt profile. Repeat this process iteratively until you have generated a minimally-permissioned Seatbelt file and have confirmed empirically that the application works normally when sandboxed using the Seatbelt profile you generated.
If the program requires external input to function fully (such as a Javascript bundler that needs an application to bundle), find sample inputs from well-known, ideally official sources. For instance, these example projects for the Rspack bundler: https://github.com/rstackjs/rstack-examples/tree/main/rspack/
