Isolation & security
Docker Runtime Hardening Contract
Status: Partially implemented — Docker profile enforcement is wired, standard is the compiled default, and rootless DinD is a recommended explicit grant; credential env-only posture remains
Shipped evidence
The hardening contract is no longer just a model. The launch path applies the profile decisions and the core decisions are unit-tested through pure launch-plan helpers.
Shipped pieces:
- Four profiles exist (
compat,standard,hardened,locked) with profile/grant defaults and runtime env names reserved against role-manifest override. no-new-privilegesis applied when sudo is off; sudo is provisioned at runtime only when the effective grant enables it.- cgroup/AppArmor probes run before launch; cgroup v1 fails closed for
hardened/lockedwhere the promised resource enforcement cannot be delivered. - Egress allowlist enforcement is wired through
firewall-applyand fails closed underhardened/lockedif the firewall cannot install the policy. lockeduses a Docker-internal role network.- DinD is tier-aware:
none,rootless, andprivilegedare selectable; rootless usesdocker:dind-rootless, fails closed where cgroup v2 is required, and is the recommended explicit grant for Docker workflows on cgroup v2. When DinD and allowlist networking are both active, the launch contract reports partial enforcement because inner containers bypass the role-container firewall. - The session contract and compact/debug telemetry report the effective profile decisions before launch.
cargo xtask profile-matrix standardrecords the default-flip compatibility matrix; the local cgroup-v2 run passed with expected rejects for runtime package installation without sudo and Docker workflows without DinD.standardis the compiled-in default.compatremains available through CLI/config/workspace/role selection for legacy privileged DinD, standing sudo, or resource-unlimited workflows.- Host Docker socket exclusion has a regression test.
- Schema, guide, and runtime reference docs for the shipped fields exist in Docker Security Profiles, Role manifest, Configuration, and Schema Versions.
Plan 043 sequencing
Plan 043 was written before WP-SUDO and WP4 landed. The keystone audit result is now complete:
| Audit question | Current answer | Evidence |
|---|---|---|
Is NOPASSWD:ALL baked into the construct image? | No. The construct installs the sudo package, but no sudoers entry is baked into the image. | docker/construct/Dockerfile |
Does jackin❯ runtime code call sudo for its own privileged setup? | No. Runtime setup that needs root uses Docker exec --user root, including sudo provisioning. | crates/jackin-runtime/src/runtime/docker_profile.rs, crates/jackin-runtime/src/runtime/launch/launch_runtime.rs |
| How is passwordless sudo granted? | Only when the resolved profile/grants set JACKIN_SUDO=1; the capsule helper writes /etc/sudoers.d/agent. When the grant is absent, the helper removes the file. | crates/jackin-capsule/src/sudo_provision.rs |
Does no-new-privileges compose with sudo? | Yes. It is enabled when sudo is off and disabled when sudo is explicitly granted, avoiding silent setuid failure. | crates/jackin-runtime/src/runtime/docker_profile.rs |
| Does built-in runtime behavior require full sudo? | No built-in jackin❯ runtime path currently requires in-container sudo. Runtime package installs remain a role/operator capability decision and should declare min_profile = "compat" or an explicit sudo grant. | docs/content/docs/(public)/guides/docker-profiles.mdx |
The remaining dependency order is:
- Keep the
standardmatrix green as new built-in roles and agent workflows are added. - Continue the independent credential env-only posture work for
hardened/locked.
Parallel hardening tracks remain independent: host.sock auth is already implemented for Linux peer credentials, DinD-inner egress residual risk is documented and tested as partial enforcement, signed releases still need end-to-end local verification, and credential env-only posture remains coordinated with the credential-exposure research.
Remaining work
- Credential env-only posture. Under
hardened/locked, prefer env-only or otherwise reduced credential exposure and emit acredential_posturedecision per agent auth type. Coordinate with Container credential exposure.
Rootless DinD default research is closed for this track: keep standard default DinD as none, recommend dind = "rootless" as the explicit Docker-workflow grant on cgroup v2, and reserve compat/privileged DinD for workflows that cannot run rootless.
Constraints that stay true
- Agent bypass flags remain enabled; Docker is the enforceable boundary, not the agent's own permission model.
- Host Docker socket exclusion is a hard rule.
- Hardened Docker is still a shared-kernel boundary; do not describe it as hostile multi-tenant isolation.
- OTLP host egress remains jackin❯-owned infrastructure and is always allowlisted for telemetry.
Related files
crates/jackin-runtime/src/runtime/docker_profile.rs— profile/grant model, flag emission, session contract.crates/jackin-runtime/src/runtime/launch/launch_runtime.rs— role container, DinD, network, launch orchestration.crates/jackin-capsule/src/sudo_provision.rs— runtime sudoers provisioning and revocation helper.crates/jackin-capsule/src/firewall.rs— in-container firewall apply primitive.crates/jackin-docker/src/docker_client.rs— typed Docker API boundary.docker/runtime/entrypoint.sh— runtime startup and agent bypass flags.docker/construct/Dockerfile— base runtime image and sudo package posture.
Related roadmap items
| Item | Relationship |
|---|---|
| Apple Container backend | macOS 26 VM backend; rootless DinD validation informs Apple Container viability. |
| Network egress policy | Future proxy-sidecar egress and connection logs beyond Docker firewall rules. |
| Declarative resource limits | Resource-budget schema and parser. |
| Process-level sandboxing | Per-command isolation inside any Docker profile. |
| Session contract and explain mode | Active profile inspection before launch. |