OpenClaw Experts
Technical

Docker Sandbox Deep Dive: Network Isolation, Resource Limits, and Security Hardening

OpenClaw Experts
••14 min read

Why Docker Sandbox Matters

A malicious ClawHub skill or successful prompt injection can execute arbitrary code on your machine. Without a sandbox, that code runs with your full privileges and can:

  • Access all files in your home directory
  • Harvest API keys, credentials, and wallet files
  • Modify or delete critical system files
  • Establish persistent backdoors
  • Exfiltrate data via network calls

A Docker sandbox runs all tool execution in an isolated container that cannot reach your host system, network, or filesystem. Even if the tool is malicious, the damage is contained.

Docker Sandbox Architecture

Isolation Layers

  1. Filesystem isolation: Tools run in a chroot/container with their own root filesystem
  2. Process isolation: Tools cannot see host processes; their PID namespace is separate
  3. Network isolation: Tools have no network access by default (can be explicitly allowed)
  4. Capability dropping: Unnecessary Linux capabilities are removed (e.g., CAP_SYS_ADMIN)
  5. Resource limits: CPU, memory, disk usage are capped per container

Configuration Guide

Step 1: Enable Docker Sandbox in OpenClaw


# ~/.openclaw/config.yml
sandbox:
  enabled: true
  engine: docker
  default_image: openclaw-sandbox:latest
  timeout: 300  # 5 minute timeout per tool
  resource_limits:
    memory: '2gb'
    cpus: '1'
    disk: '5gb'

Step 2: Configure Network Isolation

By default, sandboxed tools have no network access. To allow specific APIs:


sandbox:
  network_policy: 'deny-by-default'
  allowed_hosts:
    - 'api.example.com'
    - 'data.example.com'
  denied_hosts:
    - '169.254.169.254'  # AWS metadata (important!)
    - '127.0.0.1'        # Localhost (prevents host access)

Step 3: Drop Dangerous Capabilities

Remove Linux capabilities that tools don't need:


sandbox:
  drop_capabilities:
    - 'CAP_SYS_ADMIN'    # System administration
    - 'CAP_SYS_BOOT'     # Reboot system
    - 'CAP_NET_ADMIN'    # Network administration
    - 'CAP_SYS_MODULE'   # Load kernel modules
    - 'CAP_IPC_LOCK'     # Lock memory
  keep_capabilities:
    - 'CAP_NET_BIND_SERVICE'  # Bind to ports
    - 'CAP_CHOWN'             # Change file ownership

Step 4: Configure Volume Mounts

Be extremely restrictive about what tools can access:


sandbox:
  mounts:
    # Read-write (dangerous, use sparingly)
    - source: '/home/user/openclaw/tmp'
      target: '/tmp'
      mode: 'rw'

    # Read-only (safer)
    - source: '/home/user/openclaw/data'
      target: '/data'
      mode: 'ro'

  # Block access to sensitive paths
  blocked_paths:
    - '/home'
    - '/root'
    - '/.ssh'
    - '/etc/passwd'
    - '/var/log'
    - '/proc'
    - '/sys'

Advanced Hardening

SELinux Integration (Linux)

If running on Linux with SELinux enabled, use SELinux policies to further restrict container capabilities:


sandbox:
  selinux_label: 'system_u:system_r:container_t:s0'
  apparmor_profile: 'docker-default'

Read-Only Root Filesystem

Make the root filesystem read-only so malicious tools cannot modify the container itself:


sandbox:
  readonly_root: true
  writable_tmpfs: true  # But allow /tmp to be writable
  tmpfs_size: '100m'

Seccomp Filtering

Block dangerous system calls at the kernel level:


sandbox:
  seccomp_profile: 'docker-default'
  blocked_syscalls:
    - ptrace       # Debug/inspect processes
    - kexec_load   # Load new kernel
    - reboot       # Reboot the system

Resource Limits in Detail

Memory Limits

Prevent runaway memory usage from crashing the host:


sandbox:
  resource_limits:
    memory: '2gb'           # Hard limit
    memory_swap: '2.5gb'    # Swap limit
    memory_reservation: '1gb'  # Soft limit (warning level)

CPU Limits

Prevent a runaway tool from consuming all CPU:


sandbox:
  resource_limits:
    cpus: '1'           # Max 1 CPU core
    cpu_shares: '1024'  # Relative weight (default 1024)
    cpuset: '0,1'       # Restrict to specific cores

Disk Limits

Prevent tools from filling up your disk:


sandbox:
  resource_limits:
    disk: '5gb'           # Total disk available to container
    disk_iops: '1000'     # I/O operations per second
    disk_io_weight: '500' # Relative weight for I/O

Monitoring Sandbox Execution

Tool Execution Logs

Always log what tools execute inside the sandbox:


sandbox:
  logging:
    enabled: true
    level: 'debug'
    capture_stdout: true
    capture_stderr: true
    max_output_size: '10mb'
    audit_trail: '/var/log/openclaw/sandbox-audit.log'

Real-Time Monitoring

  • CPU usage per tool
  • Memory usage and growth
  • Disk I/O patterns
  • Network connections (should be none by default)
  • File access patterns

Testing Your Sandbox

Test 1: Network Isolation

Verify tools cannot reach the network:


# Inside sandbox, this should fail:
curl https://api.example.com
wget http://external-service.io
nc -zv google.com 443

Test 2: Filesystem Isolation

Verify tools cannot access host filesystem:


# Inside sandbox, these should fail:
ls /root
cat /etc/passwd
ls $HOME
ls /var/log

Test 3: Process Isolation

Verify tools cannot see host processes:


# Inside sandbox, this should only show container processes:
ps aux
# Should NOT show: sshd, systemd, docker daemon, etc.

Troubleshooting

Tool Cannot Access Required Files

Problem: Tool gets permission denied accessing /data
Solution: Verify mount configuration and volume permissions


# Check mounts
docker inspect <container> | grep Mounts

# Check host filesystem permissions
ls -la /home/user/openclaw/data

# Verify sandbox config has correct mount

Tool Exceeds Memory Limit

Problem: Container killed due to OOM
Solution: Increase memory limit or reduce data size

Tool Cannot Connect to Required API

Problem: Tool needs to reach api.example.com but cannot
Solution: Add to allowed_hosts in network_policy

Key Takeaways

  1. Docker sandbox is your last line of defense — even if the model is compromised, damage is contained
  2. Defense-in-depth: network isolation matters — deny network by default, allow only necessary endpoints
  3. Capability dropping prevents privilege escalation — remove CAP_SYS_ADMIN and other dangerous capabilities
  4. Resource limits prevent denial of service — CPU, memory, and disk caps are essential
  5. Test your sandbox configurations — don't assume isolation works until you've verified it
  6. Monitor sandbox execution — audit logs help detect attacks early

When to Use Unsandboxed Tools

In rare cases, you may need tools outside the sandbox (e.g., gateway management, credential rotation). For these:

  • Use minimal tool policies (deny everything except what's needed)
  • Require explicit SOUL.md approval before execution
  • Implement additional logging and approval workflows
  • Consider manual approval for sensitive operations

Related Services

OpenClaw Setup & Installation Experts
Stop fighting config files. Get a specialist to deploy OpenClaw on Mac Mini, Docker, WSL2, or any VPS faster than figuring it out alone.
OpenClaw Security & Hardening Experts
Your AI assistant has access to your files, APIs, and network. Make sure it's locked down — get a specialist for a full security audit.

Related Articles

SECURITY13 min

Prompt Injection Defense: Strategies for Multi-Model OpenClaw Deployments

Prompt injection is the most dangerous attack vector for OpenClaw agents. This guide covers model robustness, input validation strategies, and the defense-in-depth approach that makes injection attacks survivable.

SECURITY15 min

OpenClaw Security Hardening: The Complete Checklist

Running OpenClaw securely requires more than just setting a gateway password. This comprehensive checklist covers every security layer from file permissions to E2E encryption.

TECHNICAL11 min

Tool Policy Configuration: Building Deny-by-Default Access Control

Tool policies are your first line of defense against malicious skill execution. Learn how to build deny-by-default configurations, use elevated mode safely, and audit tool usage.