[Security] All sandbox modes allow connecting to privileged local daemons (Docker daemon, ssh-agent)

[yxsec]

Date: 2026-08-25
Components: @deepseek-ai/dsh-sandbox-local (macOS Seatbelt backend), @deepseek-ai/dsh-sandbox (policy helpers)
Tested version: @deepseek-ai/dsh 0.1.0-rc.7
Environment: macOS 26.5.1 (Build 25F80, arm64), Docker Desktop 4.68.0, default workspace-write session; read-only reproduced via the identical profile
Methodology: benign probes only (expected-to-fail canary writes + read-only APIs). No container created, no signature requested, no file created or modified outside temp areas.

---

Summary

The DSH process sandbox on macOS is implemented as a Seatbelt profile whose only deny rule is
(deny file-write*), confining filesystem writes to the workspace root and platform temp
directories. Every other operation axis — including outbound networking — remains under
(allow default).

A unix-domain-socket connect(2) is not a file-write* operation. Consequently, the sandboxed
agent process cannot write a single byte outside its workspace, yet it can connect without
restriction to any local service listening as the same OS user. This report verifies two such
channels:

1. Docker daemon (~/.docker/run/docker.sock): read-only API calls succeed
   (GET /_ping → OK; GET /v1.41/version returns daemon metadata). With API access, an
   agent can issue POST /containers/create with a host bind-mount and execute inside that
   container, obtaining arbitrary read/write/execute on the host as the user — the entire
   file-write fence becomes moot.
2. ssh-agent (launchd listener inherited via SSH_AUTH_SOCK): the agent protocol connects
   successfully. Once the user has identities loaded, sandboxed code can request signature
   operations through the standard protocol and act under the user's identity.

Both modes are affected. The writable-roots helper writableRoots(policy) returns a
non-empty list only when mode === "workspace-write"; the profile generated for read-only
differs from workspace-write by exactly one file-write allowlist line. The outbound-network
axis carries no rules in either mode, so socket behavior is identical.

Why it matters

1. Fence coverage does not match the threat model. Local daemons running with full user
   privileges are standard on developer machines: container runtimes, credential agents,
   language servers. When a sandbox constrains only direct file writes, these components form
   equivalent channels around the fence.
2. The Docker daemon is a second execution environment. Access to its API is equivalent to
   arbitrary execution under the user's privileges. The net effect of this finding equals
   bypassing the entire file-write fence; we suggest treating it as sandbox-escape-class.
3. ssh-agent exposure is a credential-proxy channel. Unlike file writes, signature misuse
   leaves no filesystem trace. Whenever loaded identities exist in the user session, sandboxed
   code can perform identity impersonation.
4. read-only does not reduce this exposure. The mode denies all file writes but adds no
   constraint on local IPC or network egress; for socket-based channels, the strictest mode has
   the same boundary as the default mode.

Root cause

The single place the profile is built (dsh-sandbox-local/lib/index.js):

function seatbeltProfileArgs(policy) {
    const forms = [
        "(version 1)",
        "(allow default)",
        "(deny file-write*)",
        `(allow file-write* (literal ${sbplString("/dev/null")}))`
    ];
    const roots = writableRoots(policy);
    if (roots.length > 0) forms.push(`(allow file-write* ...)`);
    return ["-p", forms.join(" ")];
}

Where writable roots come from (dsh-sandbox/lib/index.js):

function writableRoots(policy) {
    if (policy.mode !== "workspace-write") return [];
    return [...new Set([policy.workspaceRoot, "/tmp", tmpdir()].map(canonicalPath))];
}

Two conclusions follow:

1. No outbound-network rule exists anywhere in the backend package; every connect resolves to
   (allow default).
2. The only inter-mode difference is the presence of the workspace allowlist line for file
   writes; socket behavior is mode-independent.

Scoping-gap classification

Contrast experiment executed back-to-back in one session:

Action	Result	Interpretation
Write a regular file to $HOME	Kernel-denied (Operation not permitted)	the file-write* rule exists and is enforced
connect() to docker.sock followed by GET	Succeeds on the first attempt	no rule exists on the outbound-network axis

A bypass implies a denial followed by evasion. Here the first attempt succeeds because no rule
governs that axis. The correct classification is therefore missing restriction scope, and
the fix must land at the policy-generation layer; blocking individual daemons does not converge
this class of issues.

Reproduction

Option A: inside any DSH session (applies to workspace-write and read-only)

Three commands suffice:

# ① Control: write outside workspace (expected to fail)
touch "$HOME/canary"
#   → touch: ... Operation not permitted

# ② Read-only probe of the Docker daemon
curl -s --unix-socket ~/.docker/run/docker.sock http://localhost/_ping
#   → OK

# ③ ssh-agent probe (identity listing only; never signs)
ssh-add -l
#   → The agent has no identities.

Observed output (2026-08-25):

---- 1. CONTROL ----   denied at kernel level (file-write* fence active)
---- 2. Docker ----    VULNERABLE: connect() allowed, GET /_ping => OK
                       daemon meta: {"Platform":{"Name":"Docker Desktop 4.68.0 ...
---- 3. ssh-agent ---- REACHABLE: agent responded: The agent has no identities.

Full automation script in Appendix A (also saved as poc/poc.sh), including socket
auto-discovery, verdict output, and cleanup.

Option B: reproduce read-only from a plain terminal (no DSH session required)

Seatbelt cannot nest, so outside a DSH session feed DSH's exact read-only profile to
sandbox-exec:

PROFILE='(version 1) (allow default) (deny file-write*) (allow file-write* (literal /dev/null))'

/usr/bin/sandbox-exec -p "$PROFILE" touch "$HOME/x"     # → kernel-denied
/usr/bin/sandbox-exec -p "$PROFILE" curl -s --max-time 5 \
    --unix-socket ~/.docker/run/docker.sock http://localhost/_ping
#                                                        → OK

Under the same profile, the first command denied while the second succeeds completes the proof
for read-only mode. Parameterized script in Appendix B (also saved as poc/poc-readonly.sh).

Impact projection (not executed)

The following paths are stated to justify severity only; none were performed during testing:

• Docker channel: create a container with a -v /:/host bind-mount and execute within it,
  yielding arbitrary host read/write/execute as the user.
• ssh-agent channel: enumerate loaded identities and request signatures over arbitrary
  challenges, affecting commits, tags, pushes, and any other artifact accepting SSH signatures.

Proposal

In priority order:

1. Socket fencing at the profile layer (recommended). Deny outbound unix-socket connections
   by default and provide an explicit allowlist mechanism sourced from the same shared helper
   as writableRoots, preventing drift between the fs fence and the socket fence. Package
   managers and similar legitimate cases can retain exits via explicit configuration.
2. Scrub proxy-capable environment variables before spawning sandboxed shells. Remove or
   neutralize SSH_AUTH_SOCK, DOCKER_HOST, GPG_AGENT_INFO, etc. This complements
   kernel-level rules and covers backends where socket filtering is costlier to implement
   (Windows ACL).
3. Startup-time visibility. During backend probing, detect well-known privileged sockets
   reachable under the current mode and surface them in the trust footer (e.g. “workspace-write:
   local Docker socket is reachable”).
4. Document per-mode enforcement scope. State explicitly which axes each mode enforces
   (currently filesystem writes only) and which remain open (network, local IPC), enabling
   informed decisions on hosts with privileged local services.

Fixes 1+2 combined close the verified cases and the general class; 3+4 improve operator
awareness for residual environments.

Trade-offs / open questions

• Allowlist granularity: path-based socket filtering requires maintaining a list of
  legitimate consumers (e.g. package managers reaching their cache services); whether users may
  extend the list via configuration must be weighed against default posture.
• SBPL capability boundaries: macOS support for filtering unix-socket outbound traffic varies
  across OS versions; probe-stage verification that the kernel accepts the rules can reuse the
  existing fail-closed probing mechanism.
• Cross-backend consistency: Linux (Landlock/bwrap) and Windows (ACL restricted-token)
  differ in their ability to constrain local IPC; if only macOS is converged, the documentation
  should note per-platform differences.

Test methodology note

Verification used only benign canaries (writes expected to fail) and read-only API calls
(/_ping, /version, ssh-add -l). No container was created or started, no signature was
requested, nothing was created or modified outside temp areas, and all temporary artifacts were
removed. Findings should reproduce identically on any macOS host with Docker Desktop under a
default workspace-write or read-only session.

---

Appendix A: poc/poc.sh (in-session PoC)

Click to expand full script

#!/usr/bin/env bash
# poc.sh — run INSIDE a DSH session (works in workspace-write AND read-only).
# Safety: control probe is an expected-to-fail canary write; daemon probes are READ-ONLY
# APIs (GET /_ping, GET /version, ssh-add -l). Nothing is created/signed; all cleaned up.

set -u
CANARY="$HOME/.canary.$$"
hr() { printf '\n---- %s ----\n' "$1"; }

hr "0. environment"
echo "user=$(whoami)  cwd=${PWD}"

hr "1. CONTROL: file write outside workspace (expected: DENIED)"
if touch "$CANARY" 2>/dev/null; then
    echo "UNEXPECTED: write succeeded — process appears NOT confined; removing canary."
    rm -f "$CANARY"
else
    echo "denied at kernel level (file-write* fence active)"
fi

hr "2. Docker daemon reachability (READ-ONLY api calls)"
SOCK=""
for s in "${HOME}/.docker/run/docker.sock" /var/run/docker.sock; do
    [ -S "$s" ] && { SOCK="$s"; break; }
done
if [ -z "$SOCK" ]; then
    echo "no docker socket present on this host (test n/a)"
else
    echo "socket: $SOCK"
    ping="$(curl -s --max-time 5 --unix-socket "$SOCK" http://localhost/_ping || true)"
    if [ "$ping" = "OK" ]; then
        echo "VULNERABLE: connect() allowed, GET /_ping => OK"
        ver="$(curl -s --max-time 5 --unix-socket "$SOCK" http://localhost/v1.41/version 2>/dev/null | head -c 140)"
        [ -n "$ver" ] && echo "daemon meta: ${ver}..."
    else
        echo "not reachable (daemon stopped or already fenced)"
    fi
fi

hr "3. ssh-agent reachability (identity LIST only, never signs)"
if [ -n "${SSH_AUTH_SOCK:-}" ]; then
    out="$(timeout 5 ssh-add -l 2>&1 || true)"
    if [ -z "$out" ]; then
        echo "REACHABLE: protocol connected, empty reply"
    else
        echo "REACHABLE: agent responded: $(echo "$out" | head -2)"
    fi
else
    echo "SSH_AUTH_SOCK not set in this session"
fi

hr "verdict"
echo "If [1]=denied while [2]/[3] succeeded => policy covers file-write* only;"
echo "unix-socket connect rides the unrestricted outbound-network axis ((allow default))."
exit 0

Observed output (2026-08-25):

---- 1. CONTROL: file write outside workspace (expected: DENIED) ----
denied at kernel level (file-write* fence active)
---- 2. Docker daemon reachability (READ-ONLY api calls) ----
socket: /Users/<user>/.docker/run/docker.sock
VULNERABLE: connect() allowed, GET /_ping => OK
daemon meta: {"Platform":{"Name":"Docker Desktop 4.68.0 (223695)"},"Version":"29.3.1","ApiVersion":"1.54",...
---- 3. ssh-agent reachability (identity LIST only, never signs) ----
REACHABLE: agent responded: The agent has no identities.

Appendix B: poc/poc-readonly.sh (standalone terminal PoC, read-only focused)

Click to expand full script

#!/usr/bin/env bash
# poc-readonly.sh — replicate DSH's exact Seatbelt profiles OUTSIDE any DSH session
# (Seatbelt cannot nest) and show that read-only leaves unix-socket connect unrestricted.
#
# Usage:
#   ./poc-readonly.sh read-only
#   ./poc-readonly.sh workspace-write [workspace-dir]

set -u
MODE="${1:-read-only}"
WS="${2:-$PWD}"
DEVNULL_ALLOW='(allow file-write* (literal /dev/null))'

case "$MODE" in
    read-only)       ROOTS="" ;;
    workspace-write)
        ROOTS=" (allow file-write* $(for r in "$WS" /tmp "$(getconf DARWIN_USER_TEMP_DIR 2>/dev/null || echo /var/folders)"; do [ -d "$r" ] && printf '(subpath "%s") ' "$r"; done))" ;;
    *) echo "usage: $0 [read-only|workspace-write] [workspace-dir]" >&2; exit 2 ;;
esac

PROFILE="(version 1) (allow default) (deny file-write*) ${DEVNULL_ALLOW}${ROOTS}"
echo "== DSH-equivalent Seatbelt profile ($MODE) =="; echo "$PROFILE"; echo

SOCK=""
for s in "${HOME}/.docker/run/docker.sock" /var/run/docker.sock; do
    [ -S "$s" ] && { SOCK="$s"; break; }
done

echo "[1] file write to \$HOME under profile (expected: DENIED)"
if /usr/bin/sandbox-exec -p "$PROFILE" touch "$HOME/.poc-$$" 2>/dev/null; then
    echo "    UNEXPECTED: write succeeded"; rm -f "$HOME/.poc-$$"
else
    echo "    denied (fence works as designed)"
fi

if [ -n "$SOCK" ]; then
    echo "[2] docker.sock GET /_ping under the SAME profile"
    out="$(/usr/bin/sandbox-exec -p "$PROFILE" curl -s --max-time 5 --unix-socket "$SOCK" http://localhost/_ping || true)"
    [ "$out" = "OK" ] && echo "    reachable: '$out'  <-- GAP CONFIRMED under $MODE" \
                      || echo "    not reachable (daemon down?)"
    echo "[3] ssh-agent probe under the SAME profile (list only)"
    /usr/bin/sandbox-exec -p "$PROFILE" ssh-add -l 2>&1 | sed 's/^/    /' | head -2
fi
echo
echo "Interpretation: read-only denies ALL file writes yet still permits daemon connects:"
echo "the emitted policy has zero rules on the outbound-network axis."

[yxsec]

0.1.1-rc.2 also has the issue.