security: .env bind-mount changed from :ro to writable — container compromise enables full-stack credential overwrite

[yasinBursali]

Bug Report: .env bind-mount changed from :ro to writable — container compromise escalates to credential overwrite

Severity: Medium
Category: Security
Platform: All (Linux, macOS, Windows/WSL2)
Confidence: Confirmed

Description

Commit c7ffea39 (feat(settings): add secure environment editor) changed the .env bind-mount in docker-compose.base.yml from read-only (:ro) to writable for the dashboard-api container. This was done to support the new PUT /api/settings/env endpoint.

The endpoint itself is correctly protected by verify_api_key. The security regression is at the container isolation layer: the dashboard-api container now has write access to .env at the filesystem level, independent of API authentication.

Affected File(s)

• dream-server/docker-compose.base.yml line ~179
• dream-server/extensions/services/dashboard-api/main.py — PUT /api/settings/env, POST /api/settings/env/apply

Root Cause

# Before (c7ffea39 parent):
- ./.env:/dream-server/.env:ro

# After (c7ffea39):
- ./.env:/dream-server/.env

The writable mount was required to support the new in-dashboard .env editor.

Evidence

The PUT /api/settings/env endpoint calls _write_text_atomic(env_path, raw_text) which writes the merged env values directly to .env. The backup flow shutil.copy2(env_path, backup_path) also runs within the container.

_prepare_env_save validates that only schema-backed keys and existing local overrides can be changed — a sound application-level control. However, with a writable bind-mount, any code execution within the container bypasses this validation.

Platform Analysis

• Linux (systemd): Any process running as the dashboard-api container user can write to .env on the host filesystem. Host agent is 0.0.0.0 on Linux (issue Host agent binds to 0.0.0.0 — Docker control API exposed to LAN #283), so planting a known DREAM_AGENT_KEY also grants host-agent access.
• macOS (Docker Desktop): Same via the Docker Desktop VM filesystem layer.
• Windows/WSL2: Same via the WSL2 VHD bind-mount path.

Reproduction

1. Exploit any code-execution vulnerability in the dashboard-api container (e.g., SSRF chain, compromised Python dependency, future FastAPI CVE).
2. From the compromised container, write a crafted .env with a known DREAM_AGENT_KEY value.
3. Call the host agent (port 7710 on Linux, reachable from the container) with the planted key.
4. Host agent grants Docker container lifecycle control and hook script execution.

Impact

Before: container RCE → read secrets from .env (credential theft)
After: container RCE → read and write secrets → reset DREAM_AGENT_KEY, reset DASHBOARD_API_KEY, modify cloud API keys (OPENAI_API_KEY, ANTHROPIC_API_KEY), set up persistent access

This escalates container compromise from credential theft to full-stack credential overwrite.

Suggested Approach

Route .env writes through the host agent, which already writes .env for model activation in _do_model_activate. Add a /v1/env/update endpoint on the host agent with schema-validated key-value updates, and revert the dashboard-api mount to :ro. This preserves the original isolation boundary while supporting the settings editor feature.

---

Filed by automated security auditor after full-sweep of changes merged 2026-04-06 → 2026-04-11 on upstream/main @ c0600ca.

[yasinBursali]

Status check from integration test of PR stack Light-Heart-Labs#893–909

Environment: WSL2 / Ubuntu 24.04 / NVIDIA RTX 3070 Laptop / Tier 1
Branch tested: local/integration-test containing all 17 open yasinBursali PRs merged --no-ff onto Light-Heart-Labs/DreamServer@c0600ca
Install: bash install.sh --all --non-interactive --no-comfyui → phase 13, 17 healthy containers

Verdict

Security boundary FIXED by PR Light-Heart-Labs#908 — :ro mount restored, writes route through host-agent. Two adjacent issues found during testing — see notes at the end.

Evidence — :ro mount restored end-to-end

1. Mount inspection on the live container (docker inspect dream-dashboard-api):

/home/rosenrot/dream-server/.env             -> /dream-server/.env             (ro)
/home/rosenrot/dream-server/.env.example     -> /dream-server/.env.example     (ro)
/home/rosenrot/dream-server/.env.schema.json -> /dream-server/.env.schema.json (ro)
/home/rosenrot/dream-server/config           -> /dream-server/config           (ro)
/home/rosenrot/dream-server/extensions       -> /dream-server/extensions       (ro)

All four files and both directories called out in this issue (and their adjacent state) are mounted read-only inside the dashboard-api container. The .env mount is explicitly back to :ro.

2. Direct write attempt from inside the container is rejected:

$ docker exec dream-dashboard-api sh -c 'echo TEST_INJECT=1 >> /app/.env'
sh: 1: cannot create /app/.env: Permission denied

(The path is slightly different — /dream-server/.env is the mount target; the container WORKDIR is elsewhere — but the underlying filesystem is :ro either way.)

3. The new write path through the host-agent works end-to-end:

$ python3 -c "
import json, urllib.request
key='$DASHBOARD_API_KEY'
raw=open('/home/rosenrot/dream-server/.env').read()
req=urllib.request.Request(
    'http://127.0.0.1:3002/api/settings/env',
    method='PUT',
    headers={'Authorization': f'Bearer {key}', 'Content-Type': 'application/json'},
    data=json.dumps({'raw_text': raw}).encode(),
)
print(urllib.request.urlopen(req).status)
"
200

Host-agent journal:

.env updated via host agent from 172.18.0.9 (backup=data/config-backups/.env.backup.20260411-211429)
"POST /v1/env/update HTTP/1.1" 200 -

Backup file confirmed on disk:

$ ls -la ~/dream-server/data/config-backups/
-rw-------  1 rosenrot rosenrot 3830 Apr 12 00:14 .env.backup.20260411-211429

The full chain is working: dashboard-api receives PUT → forwards to host-agent at :7710/v1/env/update → host-agent validates schema → creates timestamped backup → writes new file. The original isolation boundary that this issue called out has been restored, and the new _handle_env_update route is the single writer.

Adjacent issue 1 — round-trip rebuilds the file from .env.example template

A NO-OP round trip (same file in, same file out) actually changes the file: 105 lines / 64 keys before, 229 lines / 61 keys after, with completely different comment headers. Six keys present in the input but absent from .env.example are silently dropped, including COMFYUI_GPU_UUID, EMBEDDINGS_GPU_UUID, WHISPER_GPU_UUID, JUPYTER_TOKEN, LLAMA_ARG_TENSOR_SPLIT, LLAMA_SERVER_GPU_UUIDS. No live containers broke (services don't re-read .env after start), but a future docker compose down && up -d after a settings save could pin services to defaults. Filed as #335 for tracking.

This is secondary to the security fix — the boundary works correctly. It's about round-trip fidelity, not about the threat model #317 addresses.

Adjacent issue 2 — the same :ro mount breaks PR Light-Heart-Labs#909's built-in template activation

PR Light-Heart-Labs#909 (fix(dashboard-api): non-blocking apply_template + resolve built-in extensions) adds an EXTENSIONS_DIR (built-in) fallback to _activate_service, which then calls os.rename(disabled_compose, enabled_compose) directly inside the dashboard-api container. The same extensions/ mount that Light-Heart-Labs#908 made :ro for security blocks that rename with OSError: [Errno 30] Read-only file system. Net effect: every catalog template apply now returns HTTP 500. Filed as #331 — the suggested fix mirrors PR Light-Heart-Labs#908's pattern (delegate the rename to a host-agent endpoint). Mentioning here because the two PRs are co-resident in the open stack and the conflict is direct.

What was NOT tested

• Container-RCE → DREAM_AGENT_KEY rotation chain (the actual exploit scenario) — out of scope for this QA pass.
• macOS Docker Desktop VM filesystem layer — no Apple hardware available.

Bonus observation related to this issue's "Linux platform analysis" line

On host-agent restart the new process logs:

WARNING: Agent is listening on all interfaces. Set DREAM_AGENT_BIND=127.0.0.1 in .env to restrict.

i.e. the host agent is still on 0.0.0.0:7710 by default after a fresh install. This issue's body mentions "Host agent is 0.0.0.0 on Linux (issue #283)" — and the warning suggests #283 isn't fully resolved yet either. The new DREAM_AGENT_BIND=127.0.0.1 default isn't being set by the installer.

---

Filed during full-stack integration test of open PR stack Light-Heart-Labs#893–909 on Light-Heart-Labs/DreamServer@c0600ca3. Cross-referenced from #331, #335.

[yasinBursali]

Addressed by PR Light-Heart-Labs#908 (currently draft, pending upstream review).