A Bot's shell has passwordless owner access to the database in the all-in-one image

[davidmckayv]

What is wrong

The all-in-one image runs the database and the Bot's computer as two s6 services in the same
container, and the database is created with trust authentication:

docker/s6/scripts/postgres-init.sh

initdb -D "$DATA" -A trust -U openbot
pg_ctl -D "$DATA" -o "-c listen_addresses=127.0.0.1" -w start

-A trust means any local connection is accepted as whichever role it asks to be, with no password.
-U openbot makes that role the instance owner. The script explains itself this way:

Bound to loopback and trust-auth on purpose: the only client is the process beside it, inside this
container, and a password would be a secret with nobody to keep it from. Publishing 5432 from this
container would change that, which is why nothing here does.

The premise is what is wrong. The process beside it is not only the API server. docker/s6/s6-rc.d
also starts computer, which is the service that runs /bin/bash -c on a Bot's behalf, and
agent-computer/src/shell.ts states the constraint plainly:

ISOLATION IS THE CONTAINER'S JOB. A shell can reach whatever the container can reach.

Loopback inside the container is exactly where the Bot's shell is. So in this image a Bot's shell
connects to the cluster as the instance owner without a password: the audit trail, the policy store,
the credential vault and the agent tables. Nothing needs to be published for that, and no secret has
to leak, because there is no secret.

Reaching that shell needs no exploit. computer_run_command is a governed verb and the shipped
default policy is {deny: [], allow: ["true"]}, so a fresh deployment permits it, whether driven by
the Bot's operator or by content on a page the Bot was asked to read.

The append-only trail is not a second line of defence here. The trigger refuses a delete, and the
role that owns it can drop the trigger.

This is the same class of finding as the Compose one, in the deployment shape that change does not
touch, and worse: there the credentials at least had to be read out of a file.

What should be true

The cluster should require authentication that the Bot's shell does not have, so that being inside
the container is not the same as being the database's owner. That means, roughly:

• scram-sha-256 rather than trust, with a password generated at first init and stored where only
  the API service can read it, not in the image and not in a world-readable path;
• the API connecting with that password, which means passing it between s6 services rather than
  relying on being the only process that can reach the socket;
• ideally the API using a role that is not the instance owner, so the append-only trigger is
  something its own connection cannot drop.

Worth deciding at the same time: whether computer and postgres belong in one image at all. The
Compose topology now says they do not, and the all-in-one exists for a different reason (one
container to run), so the answer may be that the all-in-one keeps them together and makes auth carry
the weight the container boundary carries elsewhere. Either way the two should not disagree silently.

How to check it is fixed

From the Bot's shell inside the all-in-one image, connecting to the local cluster as openbot
should be refused for want of a password, and the API should still start and migrate. A test that
asserts the shell can reach the socket and still cannot authenticate is the one worth keeping, since
the socket stays reachable by design.

Found while reviewing #218, which closes the equivalent gap in docker-compose.yml.

[Hotragn]

Happy to take this, and there is one thing in the "what should be true" list that I do not think can
be built as written. Raising it first because it changes the shape of the fix rather than a detail of
it.

"Stored where only the API service can read it" has no user boundary to hang on

All three services in the image run as the same Unix user:

docker/s6/s6-rc.d/api/run       exec s6-setuidgid pwuser /usr/local/bin/bun src/index.ts
docker/s6/s6-rc.d/computer/run  exec s6-setuidgid pwuser /usr/local/bin/bun src/index.ts
docker/s6/scripts/migrate.sh    exec s6-setuidgid pwuser /usr/local/bin/bun x drizzle-kit migrate

So there is no file mode that admits the API and refuses the Bot's shell. pwuser reads it either
way, and a shell is pwuser with a prompt. chmod 600 on a file owned by pwuser is not a boundary
when the thing you are keeping it from is also pwuser.

The environment is not the way out either, and for a reason this repo has already written down.
Passing the password to the api service and not to computer does stop the direct path — the shell
gets an allow-list, not process.env, since #68 — but same-uid means a shell can read another
process's environment through /proc/<pid>/environ, which is mode 0400 owned by the process's own
uid. That is the same sideways path the sudo change closed from the other end; its changelog entry
says the grant was narrowed "so apt-get install still works and sudo cat /proc/1/environ does
not". Narrowing sudo removed the root route to it. It did not remove the same-uid route, because
until now there was no secret in that environment worth reaching.

I have not reproduced the /proc read inside the image — that is the documented permission model
rather than something I ran, and it is worth one command to confirm before anybody relies on it
either way.

So the fix needs a second user, or the password needs to not exist where pwuser runs

Two shapes, and I would rather be told which:

Run computer as its own uid. Then a chmod 600 password file owned by the API's user works as
described, /proc closes with it, and it is one useradd plus a change to one s6-setuidgid. It
also makes the workspace volume's ownership a question that has to be answered, which is the part I
would want to get right rather than fast — WORKSPACE_DIR=/workspace is written by the shell and
read by nothing else, so it may be simple, but "may be" is doing work in that sentence.

Give the shell no route to the socket at all. listen_addresses=127.0.0.1 plus a Unix socket in
a directory the computer's user cannot traverse, with the cluster reachable only over the socket. This
leans on the filesystem rather than on authentication, and it argues against the issue's own framing
that the socket stays reachable by design.

My instinct is the first, with scram-sha-256 and a non-owner API role on top exactly as you
describe — the point being that auth carries the weight, and the separate uid is what makes the
password storable at all. But the second is a smaller diff and a real answer to the same question, and
the choice between them is the "whether computer and postgres belong in one image" decision you
flagged, arriving early.

One thing you should know about how I can verify it

I cannot build or boot the all-in-one image locally — no working Docker on this machine — so a change
here would be verified by CI's image and smoke jobs and not by me driving it. For a change to
initdb flags and service startup that is a worse position than I would like to be in, and it is the
sort of change where being wrong means the image does not come up.

So: if beardthelion or you would rather own this one, that is the right call and I will not be
precious about it — the analysis above is the useful part and it is yours either way. If you would
like me to build it, say which of the two shapes you want and I will send it, with the test you asked
for (shell reaches the socket, shell cannot authenticate, API still starts and migrates) and an
explicit note in the PR that CI is the only thing that has run it.