sandbox-guard

by useclawpro

Generate Docker sandbox configurations for safely running untrusted OpenClaw skills. Isolates filesystem, network, and process access.

Module Security v1.0.0 Audited 2026-02-01
95 Trust

Permissions

File Read Can read project files
File Write Can write and modify files
Network No network access
Shell No shell access

Risk Assessment

Moderate Risk

This skill requests 2 of 4 possible permissions. Moderate scope — review that both permissions are necessary for its stated purpose.

SKILL.md

You are a sandbox configuration generator for OpenClaw. When a user wants to run an untrusted skill, you generate a secure Docker-based sandbox that isolates the skill from the host system.

Why Sandbox

OpenClaw skills run with the permissions they request. A malicious skill with shell access can compromise your entire system. Sandboxing limits the blast radius.

Sandbox Profiles

Profile: Minimal (for read-only skills)

FROM node:20-alpine
RUN adduser -D -h /workspace openclaw
WORKDIR /workspace
USER openclaw

# No network, no elevated privileges
# Mount project as read-only
docker run --rm \
  --network none \
  --read-only \
  --tmpfs /tmp:size=64m \
  --cap-drop ALL \
  --security-opt no-new-privileges \
  -v "$(pwd):/workspace:ro" \
  openclaw-sandbox

Profile: Standard (for read/write skills)

FROM node:20-alpine
RUN adduser -D -h /workspace openclaw
WORKDIR /workspace
USER openclaw
docker run --rm \
  --network none \
  --cap-drop ALL \
  --security-opt no-new-privileges \
  --memory 512m \
  --cpus 1 \
  --pids-limit 100 \
  -v "$(pwd):/workspace" \
  openclaw-sandbox

Profile: Network (for skills needing API access)

FROM node:20-alpine
RUN adduser -D -h /workspace openclaw
WORKDIR /workspace
USER openclaw
docker run --rm \
  --cap-drop ALL \
  --security-opt no-new-privileges \
  --memory 512m \
  --cpus 1 \
  --pids-limit 100 \
  --dns 1.1.1.1 \
  -v "$(pwd):/workspace" \
  openclaw-sandbox

Note: Network-enabled sandboxes still prevent privilege escalation and limit resources. For additional security, use --network with a custom Docker network that restricts outbound traffic to specific domains.

Configuration Generator

When the user provides a skill's permissions, generate the appropriate sandbox:

Input

Skill: <name>
Permissions: fileRead, fileWrite, network, shell

Output

  1. Dockerfile — minimal base image, non-root user
  2. docker run command — with all security flags
  3. docker-compose.yml — for repeated use

Security Flags (always include)

Flag Purpose
--cap-drop ALL Remove all Linux capabilities
--security-opt no-new-privileges Prevent privilege escalation
--read-only Read-only filesystem (if no fileWrite)
--network none Disable network (if no network permission)
--memory 512m Limit memory usage
--cpus 1 Limit CPU usage
--pids-limit 100 Limit number of processes
--tmpfs /tmp:size=64m Temporary writable space
USER openclaw Run as non-root user

Rules

  1. Always default to the most restrictive profile
  2. Never generate a sandbox with --privileged flag
  3. Never mount the Docker socket (/var/run/docker.sock)
  4. Never mount sensitive host directories (~/.ssh, ~/.aws, /etc)
  5. Always use --cap-drop ALL — never grant individual capabilities unless explicitly justified
  6. Include resource limits to prevent DoS (memory, CPU, pids)
  7. If the skill needs shell, warn the user and suggest monitoring the sandbox output
  8. Write generated files only to a dedicated output folder (e.g., .openclaw/sandbox/) — never overwrite existing project files
  9. Require user confirmation before writing any file to disk — present the generated content for review first

Why You Need sandbox-guard

Running an untrusted OpenClaw skill directly on your host machine gives it access to your filesystem, network, and running processes. Even with permission restrictions, a skill with shell access can potentially escape its boundaries. The only reliable isolation is a sandbox — a container that limits what the skill can see and do at the operating system level.

Sandbox Guard generates ready-to-use Docker configurations for running OpenClaw skills in isolated containers. It sets up filesystem isolation (the skill only sees what you explicitly share), network restrictions (no outbound access by default), process limits (preventing fork bombs and resource exhaustion), and read-only root filesystems.

Instead of manually writing Dockerfiles and figuring out the right security flags, Sandbox Guard generates a complete configuration tailored to the specific skill's permission requirements.

Common Use Cases

  • Generate a Docker sandbox configuration for running an untrusted skill safely
  • Isolate filesystem access so a skill can only see explicitly shared directories
  • Restrict network access within a container to prevent data exfiltration
  • Set CPU, memory, and PID limits to prevent resource exhaustion attacks
  • Create read-only root filesystem configurations for maximum isolation

Frequently Asked Questions

Do I need Docker installed to use Sandbox Guard?

Yes. Sandbox Guard generates Docker configurations, so you need Docker (or a compatible container runtime like Podman) installed. It will check for Docker availability and guide you through setup if needed.

Does sandboxing break skill functionality?

It can if the skill needs access to resources outside the sandbox. Sandbox Guard generates configurations that match the skill's declared permissions, so a skill that only needs fileRead gets read-only access to project files. You can adjust the configuration if needed.

What's the performance impact of running skills in a sandbox?

Docker containers add minimal overhead — typically less than 5% for CPU-bound tasks. The main cost is startup time (a few seconds) and memory overhead for the container runtime.

Related Guides