[Security] a failed sandbox probe still gives the agent the Docker daemon, without verifying that it blocks host escapes

Summary

A failed sandbox probe still hands the agent the sandbox Docker daemon, so the worker runs with Docker access that was never verified against host-escape requests. PentAGI runs a probe container at startup; when the probe cannot write its result file, no check is emitted, but the parser accepts the info/totals/daemon ID and the verdict is sandbox isolation verified with checks=0. The worker is then created with DOCKER_HOST pointing at the sandbox daemon. The deployment believes the isolation was checked; in reality the agent can attempt privileged containers or daemon abuse against a daemon that was never verified to refuse them. The trigger is local (the probe container's filesystem), but the effect is the loss of the control that gates the agent's Docker access.

Details

Affected component

backend/pkg/docker/sandbox.go (parseSandboxReport, decideSandbox, probeSandbox), backend/pkg/docker/sandbox_probe.sh, backend/pkg/tools (RunContainer).

Vulnerable code

backend/pkg/docker/sandbox.go:270-283:

if len(report.failed) > 0 {
    dc.disableSandbox(cfg, logger.WithFields(logrus.Fields{
        "daemon": report.daemonID, "failed_checks": report.failed,
        "passed": report.passed, "total": report.total,
    }), "the sandbox daemon did not pass the isolation test")
    return
}

logger.WithFields(logrus.Fields{
    "daemon": report.daemonID, "authorization": report.authz, "checks": report.total,
}).Info("sandbox isolation verified: agents reach a separate Docker daemon that refused every " +
    "host-escape request and served every legitimate one")

parseSandboxReport requires sawInfo && sawTotals && daemonID != "", but does not require any check lines; runSandboxProbe reads stdout only and ignores the probe's exit code.

Root cause

The verdict treats "no failed checks" as "verified", and a report with zero checks also has zero failures. The parser does not distinguish "the probe ran and all checks passed" from "the probe failed before emitting any check". The probe script's failure mode is silent: background groups die at their first write when the results file cannot be written, the parent still emits a totals line with 0/0/0 and exits 0.

Attack path

1. A deployment starts PentAGI with sandbox checks enabled; the worker probe runs at startup.
2. The probe container cannot write its results. The simplest realistic forms are a read-only filesystem, a full disk, or a file-size limit; the reproduction below uses a file-size limit because it is a single shell setting, and every form produces the same zero-check report.
3. parseSandboxReport accepts the info + totals + daemon ID; decideSandbox sees no failures and logs sandbox isolation verified with checks=0.
4. The server keeps running; a flow is created through the REST API.
5. RunContainer creates the worker with DOCKER_HOST pointing at the sandbox daemon; the agent gets the daemon even though the probe never verified that the daemon refuses host-escape requests.

Affected deployments

Deployments that enable the sandbox check and rely on it to gate the worker's Docker access. The probe is part of startup, so the fault is local (the probe container's environment), not remote.

Remediation

Require a minimum number of checks (and a summary with total > 0) before treating the report as verified; treat a zero-check report, a parse failure, or a non-zero probe exit as a failed verification and disable the sandbox (or fail startup). Add the probe exit code and a checks=0 guard to the verdict; surface the result in health/status.

Related public reports

Issue #101 is a public security report about default credentials and the container/host boundary. This report is different: it concerns the zero-check probe verdict that gates whether the worker receives the sandbox daemon.

Proof of concept

Start the server with the sandbox check enabled and make the probe container unable to write its result file (for example run the probe image with ulimit -f 0 in its shell).

Fault:

probe stdout: info + {"kind":"summary","total":0,"passed":0,"failed":0}
server log:   "sandbox isolation verified ... checks=0"
server:       API server listening
POST /api/v1/flows/ -> 201, {"id":1}
server log:   "flow created in DB" -> "running container" -> "container created"
docker inspect <worker>: DOCKER_HOST=tcp://...:2375

Baseline (probe container writable): sandbox isolation verified ... checks=35; a daemon that permits a privileged container yields 34/35, sandbox DISABLED, and the worker gets no DOCKER_* environment.

Expected difference: a writable probe reports 35 checks; a probe that fails to write reports 0 checks but is still "verified", and the worker is created with the sandbox daemon attached. The only changed variable is the probe container's ability to write its report.

Impact

The check is the only gate that decides whether the agent gets Docker at all. A zero-check report disables that gate silently: the worker receives the daemon, the deployment logs "verified", and an agent steered by untrusted content can attempt privileged containers, host mounts, or daemon-level actions against a daemon that the product never proved would refuse them. The failure removes the verification, not just a log line.

Affected products

• Ecosystem: other (Go binary; Docker images)
• Affected versions: <= 2.2.0
• Patched versions: (none)

Weaknesses

CWE-636 (Not Failing Securely), CWE-693 (Protection Mechanism Failure).

Reporting note (why this is a regular issue)

This repository has a private advisory entry, but I could not find a SECURITY.md or any other documented reporting policy. Since there is no documented process for private reports, I am filing this as a regular issue. If there is a preferred private channel, please let me know and I will be glad to move the report there. I have not published this elsewhere.