ducoterra
144e322391
Everything else in the file gates egress, which left an everyday request unanswered: the agent starts a dev server inside the sandbox and a human wants to look at it. This puts a listener on the host that forwards into the container, so a browser, curl or an API tester reaches the server the sandboxed process runs. `--publish [ADDR:]HOST:CONTAINER`, config `publish` and AISB_PUBLISH, repeatable, with the cost named in the flag: it is ingress, so whatever that server serves is reachable from the address it binds. The default address is 127.0.0.1 because a bare podman -p binds every interface (measured) -- a port committed in a repo config must not quietly be a port on the LAN. publish_addr changes the default machine-wide; a spec with a non-loopback address warns on every run. The grammar is smaller than podman's on purpose: one port per entry, no ranges, no /udp, no `*` -- this list is reviewed line by line, and typing 0.0.0.0 is the whole warning. An address means three parts, so `127.0.0.1:8000` is refused rather than guessed. No -p alias: that flag belongs to the harness (claude -p prints). Fail closed, as elsewhere: --net none cannot forward a port and podman discards the mapping while starting the container anyway, so "it ran" would mean "nothing is listening"; a host port already in use is named before the container starts, not after a build; pick_port() will not hand the gate a port this run publishes. The container is labelled with the ports it was given, and doctor reports them. Inside, publish_rules() accepts tcp on the published ports in the input chain and never the output one. Measured (docs/networking.md): pasta delivers the connection over loopback, so that rule counts 0 packets on the reference host; it is there for a host or a bridge network that delivers on the interface, and so that `nft list table inet aisb` answers "what can reach this container". The ports are validated again inside the entrypoint, because a ruleset is not somewhere to splice an unvalidated string. And the measurement that makes a configured preview look broken: a server bound to 127.0.0.1 inside answers inside and refuses the published port outside, so dev servers must bind 0.0.0.0 -- both skills say so in the change that writes the port. Tests. Unit: the grammar and every port list that looks right and is not, config/env/flag precedence and dedup, the canonical spec in --print-policy, the `# ingress:` header, the flags reaching the invocation before the image, egress enforcement byte-identical with a port open, which chain the rule lands in and that a non-numeric port never reaches nft as code. e2e (tests/e2e/13_publish.sh): one real container with enforce=nft where the host gets its 200 and the same run still refuses a domain outside the allowlist at 403, the server runs as uid 1000 with no capabilities so it cannot widen its own port, and the host listener is gone when the container exits. LLM-Generated: true
130 lines
10 KiB
Markdown
130 lines
10 KiB
Markdown
# Threat model
|
|
|
|
Read this before relying on `ai-sandbox`. It is a **seatbelt, not a jail**: it
|
|
raises the cost of an agent's mistakes and of a moderately compromised prompt
|
|
context, on a machine you still log into as yourself.
|
|
|
|
## Who we assume is hostile
|
|
|
|
The modelled adversary is **the agent you are running**: an LLM harness with your
|
|
write access to one directory, capable of running arbitrary shell commands, and
|
|
vulnerable to prompt injection from the files it reads, the web pages it fetches,
|
|
and the package changelogs it installs. We assume it will try to escape when a
|
|
prompt injection tells it to.
|
|
|
|
We do **not** model a kernel-level adversary, a hostile container image from a
|
|
registry you don't control, or someone with access to your host user account.
|
|
|
|
## What stops working (defence in depth, most to least load-bearing)
|
|
|
|
| Attack | Stopped by | Evidence |
|
|
|---|---|---|
|
|
| Editing / deleting anything outside the project directory | `$PWD` is the only writable mount; the rest of the host is not in the mount namespace | `tests/e2e/12_sandbox.sh` |
|
|
| Rewriting your skills, prompts or global `AGENTS.md` | `~/.agents` is mounted, but read-only, and there is no flag to change that | `tests/e2e/12_sandbox.sh` |
|
|
| Reading `~/.ssh`, `~/.aws`, `~/.config/gcloud`, browser profiles | same as above; those paths do not exist in the container | `tests/e2e/12_sandbox.sh` |
|
|
| Exfiltrating your environment (API keys for *other* services) | nothing is passed through unless named with `--env` | `tests/unit/04_env.sh`, `tests/e2e/12_sandbox.sh` |
|
|
| Passing secrets through the process list to other users | values travel in a `0600` file, never in argv | `tests/e2e/12_sandbox.sh` |
|
|
| Egress to an arbitrary host (curl, python, a raw socket, a bespoke exfil tool) | netfilter `policy drop` inside the container's namespace | `tests/e2e/11_net.sh` |
|
|
| Egress through the proxy to a non-allowlisted domain, including HTTPS | squid's `http_access deny all` after the allowlist | `tests/e2e/11_net.sh` |
|
|
| Deleting or weakening the egress ruleset | the command runs with no capabilities; `CAP_NET_ADMIN` was dropped across `exec` | `tests/e2e/11_net.sh` |
|
|
| `unshare -n` to get a fresh namespace with its own routes | requires `CAP_SYS_ADMIN`, which the command does not have | `tests/e2e/11_net.sh` |
|
|
| Privilege escalation via a setuid binary in the image | `--security-opt no-new-privileges` + `--cap-drop=ALL` | container config, asserted in `tests/e2e/10_image.sh` |
|
|
| Reaching other host services on loopback | only the gate's port is routable through the mapped loopback address | `tests/e2e/11_net.sh` |
|
|
| Fork bombs, memory bombs, runaway builds | `--pids-limit`, `--memory`, `--cpus`, `--tmpfs` sizes | `tests/e2e/10_image.sh` |
|
|
| Writing to the host's package manager, `/etc`, global npm/pip | read-only-ish image, `HOME` inside the container, optional `--read-only` | `tests/e2e/12_sandbox.sh` |
|
|
| Credential persistence you did not ask for | `--ephemeral-home`; the default home volume is named and inspectable | `tests/e2e/12_sandbox.sh` |
|
|
| Silent wide-open starts | an empty allowlist in `allow` mode is a hard error | `tests/unit/01_args.sh` |
|
|
| An agent shipping work you have not looked at (`git push`) | the git remote is not in the allowlist, so nothing in the container can reach it; `ai-sandbox-autophase` commits and pushes on the host, outside the sandbox, between unit runs | `tests/unit/10_autophase.sh` |
|
|
| The gate becoming the escape (`validate.sh` is inside the writable mount) | the pass/fail gate runs in the sandbox as the same unprivileged user, not on the host | `tests/unit/10_autophase.sh` |
|
|
|
|
## What does **not** stop it
|
|
|
|
Be honest about these, and design your work accordingly.
|
|
|
|
1. **Anything you allowlist is reachable, in both directions.** Allow
|
|
`api.github.com` and a prompt-injected agent can push your code to a repository
|
|
it controls, using the token you deliberately handed it. The allowlist limits
|
|
*where*, not *what*. Prefer least-privilege, read-only, short-lived tokens.
|
|
2. **The project directory is genuinely writable.** A bad `rm -rf`, a force push, a
|
|
corrupted lockfile all still happen — just confined to that directory. Keep the
|
|
tree committed (`ai-sandbox doctor` warns you when it is dirty).
|
|
3. **Kernel and runtime escapes.** A container is not a VM. A container escape
|
|
vulnerability in runc/crun or the kernel gets an attacker to your user account.
|
|
For genuinely untrusted code, use a VM or a disposable machine.
|
|
4. **`--net full` and the escape hatches do what they say.** `--allow-unenforced`,
|
|
`--insecure-keep-root`, `--mount`, `AISB_EXTRA_ARGS`, `--net full` all weaken the
|
|
posture. They are named to be uncomfortable on purpose; nothing uses them
|
|
implicitly.
|
|
5. **Side channels.** Timing, resource consumption, and "the agent typed X into a
|
|
form on a site you allowed" are out of scope.
|
|
6. **A cached home volume can hold credentials.** If a harness logs in inside the
|
|
sandbox, the token lives in the `aisb-home` volume, and any later sandbox run
|
|
using that volume can read it. `--ephemeral-home` per run, or a dedicated
|
|
`AISB_HOME_VOLUME` per trust level.
|
|
7. **DNS is closed in gate mode, open in `--no-gate` mode.** With `--no-gate`, name
|
|
lookups leave the container; that is a modest data channel and a fingerprint of
|
|
what you are doing. Egress to non-allowlisted IPs stays blocked either way.
|
|
8. **The gate sees everything that flows through it** — including any credentials
|
|
in proxied requests. That is the point of an egress proxy; the squid config logs
|
|
to its own container log, and `gate logs` shows them. Do not put secrets in URLs.
|
|
9. **Supply chain inside the allowlist.** `registry.npmjs.org` allowlisted means any
|
|
package, including a typosquatted one, can be fetched. Allowlisting a domain is
|
|
not a security review of what you install from it.
|
|
10. **Rootless podman still means shared kernel and shared UID namespace.** Files
|
|
the container writes are owned by *you*. There is no uid boundary between
|
|
"agent's file" and "your file" beyond ownership metadata and your own discipline.
|
|
11. **Your `~/.agents` is readable inside the sandbox.** This is a deliberate
|
|
exception to "only your project directory is mounted", because a harness without
|
|
your skills is a harness you re-brief every run: `~/.agents` arrives read-only at
|
|
`/home/sandbox/.agents` (`--no-agents` for a run without it, `--agents-dir` for a
|
|
curated set). Read-only means the agent cannot write a `SKILL.md` that you will
|
|
follow tomorrow on the host — that is the part that matters, and it holds even under
|
|
`--insecure-keep-root`. It does *not* mean the contents are secret: the whole tree,
|
|
including its `.git` history and any token someone pasted into a skill, is readable
|
|
by whatever you run in there. Treat a shared skill directory as published to the
|
|
agent, lint it for secrets (`skill-lint`), and keep credentials in the environment
|
|
you pass explicitly rather than in a file that is mounted everywhere.
|
|
12. **The pi bridge reads a file that may hold a live key.** It rewrites `apiKey` to
|
|
an environment reference and never copies `auth.json`, but the *endpoint* in your
|
|
`models.json` becomes an endpoint the sandbox can be pointed at, and the token it
|
|
uses is your real one. So the bridged config is a convenience, not a narrower
|
|
credential: prefer a per-sandbox token from your gateway if it can mint one, and
|
|
note that a bridged run whose token variable is unset or empty is refused rather
|
|
than started. Sandboxed edits to `~/.pi/agent` persist in the home volume and win
|
|
over later host changes (see the README), which is convenience with a consequence: a
|
|
hostile run could rewrite the sandboxed pi config for later runs of that volume —
|
|
point `baseUrl` at a host it controls, swap a model, change the provider. Merging
|
|
`settings.json` per key limits this (a run can only pin the keys it actually writes,
|
|
and everything else keeps following your host config), and `defaultThinkingLevel` is
|
|
re-forced every run so a run cannot quietly lower the reasoning of the next. It is
|
|
not eliminated: `--ephemeral-home` removes it, and `inspect` shows what is bridged.
|
|
|
|
13. **A push on the host still pushes what the agent wrote.** `ai-sandbox-autophase`
|
|
keeps the remote away from the sandbox, but somebody has to deliver the work, and
|
|
that somebody is the harness running as you. It commits only the phase's own
|
|
changes and only after `.agents/validate.sh` passes — so read that gate as part of
|
|
your trust base. It lives in the writable mount, which is exactly why the gate runs
|
|
*in the sandbox* by default; `--validate-in host` hands that judgement to you and
|
|
warns on every run.
|
|
|
|
14. **A published port is a door you opened.** `--publish` (and `publish` in a config
|
|
file) puts a listener on the host that forwards into the container, so a client
|
|
outside can reach a server the agent is running. That is the feature — preview a dev
|
|
server, poke a local API — and it is also the whole risk: whatever that server serves,
|
|
and whatever it accepts, is reachable from the address it is bound to, by things other
|
|
than you. The default binds `127.0.0.1`, because a bare podman `-p` binds every
|
|
interface (measured); a spec with a non-loopback address warns on every run and should
|
|
not be committed. Egress stays enforced either way: a published port is ingress, not a
|
|
loosened allowlist, and the same run that answers your browser still refuses a domain
|
|
outside it (`tests/e2e/13_publish.sh`). The agent inside cannot widen its own port or
|
|
open a new one — the mapping is decided on the host before the container starts and the
|
|
command runs with no capabilities. What it *can* do is serve whatever it likes on a port
|
|
you asked for. Publish the port of the server you meant to preview, and treat that port
|
|
as published content for as long as the run lasts.
|
|
|
|
## Residual risk rating
|
|
|
|
*Accidental destruction and ambient credential leakage: largely eliminated.*
|
|
*Deliberate data exfiltration over an allowlisted path: mitigated, not prevented.*
|
|
*Container escape to the host: out of scope, accept it or use a VM.*
|