Is it possible to prevent docker socket escape

[merikan]

I am using nono to sandbox my coding agent and it works great. However, most of my java projects are using testcontainers so the agent needs access to docker to be able to run my integration tests. I have enabled access to the docker socket etc. to be able to run docker in the sandbox and it works great.

However, since the agent has access to the socket it can mount a volume and escape the sandbox, that kind of defeats the purpose of the sandbox. Is there any way to prevent the agent from escaping via the docker socket, or is the only way not to allow running Docker containers in the sandbox?

I am on MacOS and using Docker Desktop, but colima, rancher, podman are also candidates in case that would work better.

I have looked into docker-socket-proxy but couldn't find a way forward. I was thinking if, maybe I could spin up a new docker server in a VM that only has access to the current directory and share that socket?
Anyway, any help is appreciated.

[dfbustosus]

Giving the agent a Docker socket delegates the authority of that Docker daemon. Once it can call POST /containers/create, it can request bind mounts, privileged mode, host namespaces, devices, and capabilities. nono cannot stop operations performed by the daemon on the agent's behalf, and filtering Docker CLI arguments is insufficient because Testcontainers calls the API directly.

Your dedicated-VM idea is the correct boundary.

A practical design is:

1. Run a disposable Docker daemon in a separate VM or remote host dedicated to agent tests.
2. Expose only that daemon to the sandbox through DOCKER_HOST or a dedicated Docker context; do not grant the Docker Desktop socket.
3. Mount only the current project into the VM. Do not share the full home directory, SSH directory, cloud credentials, or the host Docker socket.
4. Let Testcontainers create privileged containers inside that VM if required, while treating the entire VM as disposable.
5. Recreate or reset the VM between untrusted runs if you need a stronger cleanup guarantee.

On macOS, a separate Colima/Lima VM can provide this boundary, but inspect its mount configuration carefully because convenient defaults may share more of the home directory than intended. A separate Docker Desktop context that points to the same daemon is not isolation; it must be a different daemon in a different VM.

Rootless Docker reduces the daemon's authority over its host, but it does not protect files, sockets, credentials, or processes that are visible to that daemon/user. It is useful defense in depth inside the dedicated VM, not a substitute for the VM boundary.

A Docker socket proxy is only safe here if it semantically validates every operation. Merely allowing the endpoints Testcontainers needs is not enough: container creation itself must reject arbitrary bind mounts, privileged, host PID/network/IPC modes, devices, dangerous capabilities, and equivalent escape paths. Testcontainers uses a broad, changing subset of the API, so maintaining such a policy correctly is usually more fragile than isolating the daemon.

The resulting trust model is:

agent + nono
    -> dedicated Docker API
        -> disposable VM
            -> only project directory exposed

An escape through the Docker API then grants control of the disposable VM, not your macOS account or primary Docker Desktop environment.

This matches nono's own security model: it controls declared filesystem/process/network capabilities but is not a VM or kernel boundary, and it recommends an outer container or microVM when stronger isolation is needed. References: nono security boundary, outer isolation guidance, Docker daemon security, and remote daemon configuration.

[merikan]

Thank you @dfbustosus for a great and detailed answer. Good to know I was on the right track, so I'll keep going with that and see where I end up.

[lukehinds]

@dfbustosus has it right, with nono its a challenge to do these things from user-space, yet we don't want to elevate from user space to the kernel as this nice part about nono it runs anywhere -

we are going to introduce optional namespacing though, which prevent all of these. and of course the other option is firecracker or kata and hopefully docker sandboxes is landlock is enabled.

[merikan]

Thanks for the answers. I decided to use Lima to spawn up a Docker engine and mount that to the current folder, for each project needing their own Docker engine. I went down the rabbit hole with Firecracker, but I didn't have enough time, so I had to stop. Maybe I will pick it up later.

However, Instead of exposing my DOCKER_HOST environment variable by mistake, I decided to use a different name, SANDBOXED_DOCKER_HOST, and then rename it in the sandbox. The only way I found to accomplish this was using the env_credential. I know it's not really considered a credential, but it was the only way I could find to solve my problem.

  "filesystem": {
    "read": [
      "~/.docker",
    ],
    "unix_socket": [
      "$DOCKER_HOST"
    ],
  },
  "env_credentials": {
    "env://SANDBOXED_DOCKER_HOST": "DOCKER_HOST"
  }

Some of my projects need a Docker Host in the sandbox and some don't. Unfortunately, If I don't set the variable before entering the sandbox, nono complains about it.

  warning: env credential 'env://SANDBOXED_DOCKER_HOST' exposes the secret directly to the sandboxed process.
             For network API keys, use a profile with credentials for credential isolation.
nono: Secret not found in keystore: environment variable 'SANDBOXED_DOCKER_HOST' is not set

Since I want to use the same profile for all my projects, my current workaround is to set the value "NONE" globally.

Is it possible to make the env_credential optional? Or is there a better way to solve this?

[merikan]

Since it's an environment variable, the following would be nice.

"environment": {
  "deny_vars": ["DOCKER_HOST"],
  "map_vars": {
    "DOCKER_HOST": "SANDBOXED_DOCKER_HOST"
  }
}

Note the direction: the key is the name inside the sandbox and the value is the host variable. env_credentials uses the opposite direction (source → target). Matching set_vars is probably a better choice because both write sandbox variables.

I am not sure about the name, maybe rename_vars and from_host is better.
And the variable should be optional. If not found, a mapping is not done.

[merikan]

I thought it was such a good idea myself that I created a feature request. #2077