Hacktoberfest 2026: los issues que los mantenedores marcaron para octubre, abiertos y aptos para principiantes. Explorar issues de Hacktoberfest

Container create: default-deny HostConfig, validate Mounts and the bind read-only mode

Abierto
  • ¿Algo no está bien?
#88 0 comentarios 0 reacciones 0 asignados Ver en GitHub

Los mantenedores suelen responder en 1 día

Nadie ha tomado este issue todavía.

Evaluación

Dificultad
4/5
Tiempo estimado
3-5 días
Aptitud para principiantes
15/100
Tipo de issue
Error
Claridad
Bastante claro
Estado de actividad
Activo
Stack tecnológico
docker, go, rust, typescript
Área
api, security

Línea de trabajo

Start with the POST /containers/create middleware in go/internal/middleware/mountsource.go and containerconfig.go, then the matching files in rs/src/middleware.rs and ts/src/middleware.ts. The issue asks for a default-deny allowlist on HostConfig, a Mounts check that matches the Binds whitelist, bind-mode parsing for read_write, and forcing Privileged to false even when container_config is empty. Done means the three repro creates return 403 in each implementation, and the policy tests cover the new rules. The issue is a breaking security change that needs maintainer agreement on the allowlist first.

Escrito por el modelo de indexación a partir del texto del issue.

Descripción

Priority: P0 Status: Break Change Type: Bug

Describe the bug

On POST /containers/create, the proxy checks only part of the request. Every other field goes to the daemon unchanged:

  • The volume whitelist checks the host path of HostConfig.Binds and the legacy top-level Volumes. It does not check HostConfig.Mounts.
  • The bind mode is not checked. read_write: false is parsed in all three implementations, but no gate reads it.
  • ContainerConfigMutator overwrites NetworkMode, RestartPolicy, SecurityOpt, Privileged, User and LogConfig. If container_config is empty, it returns early and does not even force Privileged: false.
  • Other HostConfig fields pass through: Devices, DeviceRequests, DeviceCgroupRules, GroupAdd, CapAdd, VolumesFrom, Links, Sysctls, CgroupParent, Runtime, the host values of PidMode, IpcMode, UTSMode, UsernsMode and CgroupnsMode, MaskedPaths/ReadonlyPaths, and SecurityOpt when the policy sets none.

So every policy-level restriction on mounts and privileges can be bypassed by a caller of the socket.

Affected implementation(s)

  • Go
  • Rust
  • TypeScript
  • All

Go go/internal/middleware/mountsource.go (Binds host path only), go/internal/middleware/containerconfig.go:13 (early return). Rust rs/src/middleware.rs and TypeScript ts/src/middleware.ts have the same gaps.

To Reproduce

Policy with volumes: [{host_path: /srv/ok, container_path: /ok, read_write: false}]. Through the proxy, each of these creates is accepted and the daemon receives the field unchanged:

  1. docker create --mount type=bind,src=/,dst=/host alpine:3.20 true
  2. docker create -v /srv/ok:/ok:rw alpine:3.20 true (also -v /srv/ok:/ok with no mode)
  3. docker create --cap-add SYS_ADMIN --pid host alpine:3.20 true

Expected behavior

Default-deny on HostConfig:

  1. A HostConfig key outside a fixed allowlist must be absent or hold its zero value. Otherwise the proxy returns 403 and names the field. A denylist would miss fields that the Engine API adds later.
  2. HostConfig.Mounts gets the same whitelist as Binds. bind mounts must match a policy volume, with ReadOnly: true if the volume is not read_write. volume mounts and all other types except tmpfs are denied.
  3. Each bind mode is parsed. A volume with read_write: false requires ro.
  4. The mutator forces Privileged: false even if container_config is empty. SecurityOpt from the caller is denied unless the policy lists it, apart from no-new-privileges.

Status: Break Change: creates that set these fields are now denied.

Additional context

Found while verifying the proxy for ChainSafe/lodestar-infrastructure#9.

Lenguaje dominante
Rust
Estrellas
2
Forks
0
Merge medio
13 h 22 min
PR fusionados (30 d)
27

Preparar el entorno

Primeros pasos

  1. Lee el issue completo y luego la guía de contribución del proyecto.
  2. Comenta en el issue que vas a ocuparte — evita que dos personas hagan lo mismo.
  3. Haz un fork del repositorio y trabaja en una rama.
  4. Abre un pull request que haga referencia al número del issue.

Más de ChainSafe/docker-socket-policy

Todos los issues de ChainSafe/docker-socket-policy

Issues similares

Más issues de Rust

Recibe los nuevos issues en tu correo

Un resumen breve de issues de GitHub para principiantes.