docs: correct container option injection boundary (#253)

docs/security-model.md

@@ -157,7 +157,7 @@ Detail: [Running containers](../apps/sisyphusd/README.md#running-containers).
 
 What that does not do:
 
-- **The image is whatever the submitter names.** The name is checked only so far that Docker cannot read it as an option: one that begins with a dash, or has a space or control character in it, is refused when the job is submitted and again by the worker (`checkImage`). Before that check a job could add Docker options of its own, mounts and `--privileged` among them; a worker on a build without it is still open to that. Naming an image by digest pins what runs only if the submitter wants it pinned.
+- **The submitter chooses the image and the program it runs, but not Docker's options.** The worker constructs the `docker run` arguments itself; the job supplies an image, an in-container command and environment, and the declared task limits/network choice. The image name is checked both when the job is submitted and again by the worker (`checkImage`), and the command follows the image in Docker's argument list. A job therefore cannot add engine flags such as `--privileged` or arbitrary host mounts through these fields. The program inside the chosen image is still untrusted code, and may use whatever access the worker's configured confinement permits. Naming an image by digest pins what runs only if the submitter wants it pinned.
 - **No sandbox beyond that, unless the worker's owner asks.** By default the root filesystem is writable, and the container shares the worker's kernel. `--containers-read-only` makes the root read-only, with `/tmp` in memory; `--container-runtime` has Docker use a sandboxed runtime the owner has installed, such as gVisor's `runsc` or Kata's (`packages/runtime/container.go`, `Confinement`), and the node refuses to start if Docker does not have it. Neither runtime has been tried with this code. Nothing limits what is written to the worker's disk through `/output` while the command runs, and there is no user namespace. A node run as root runs containers as root, though with no capabilities; where the system has no user numbers, the image's user is used and Docker's usual capabilities are kept, since an image that installs what it needs as root would not run without them.
 - **Limits are the submitter's, not the worker's.** A worker's `--offer-memory-mb` is what it advertises and is not enforced.
 - **Output is bounded, loosely.** What the command prints is kept up to 16 MiB as the task's output. Each line of it is also a log line, cut at 4 KiB by the worker and again by the coordinator, which keeps 20,000 lines for a job and then says once that it keeps no more (`coordinator.go`, `logLocked`). Files left in `/output` are stored up to 4 GiB and 1,024 files for a task, beyond which the task fails; the limit is on what is stored, not on what the command may write while it runs.