bug: setup hook subprocess in _run_install inherits full host-agent environment — AGENT_API_KEY exposed to hook scripts

[yasinBursali]

Bug Report: setup hook subprocess in _run_install inherits full host-agent environment — AGENT_API_KEY exposed to hook scripts

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

Description

The _run_install worker function inside _handle_install runs the extension's setup hook via subprocess.run without specifying an env= argument. This means the subprocess inherits the complete environment of the host agent process, including AGENT_API_KEY, DREAM_AGENT_KEY, DASHBOARD_API_KEY, and any other secrets loaded at startup. By contrast, the _execute_hook path (used by _handle_hook and _handle_setup_hook) was explicitly designed with a minimal allowlist env. The two paths are inconsistent.

Affected File(s)

• dream-server/bin/dream-host-agent.py (L936–944, inside _run_install in _handle_install)

Root Cause

# dream-host-agent.py L936-940 — setup hook in _run_install:
result = subprocess.run(
    ["bash", str(hook_path), str(INSTALL_DIR), GPU_BACKEND],
    cwd=str(ext_dir),
    capture_output=True, text=True,
    timeout=SUBPROCESS_TIMEOUT_START,
    # No env= argument — inherits full host-agent process environment
)

Compare with _execute_hook (L856-866) which builds an explicit allowlist:

hook_env = {
    "PATH": ..., "HOME": ..., "SERVICE_ID": ...,
    "SERVICE_PORT": ..., "SERVICE_DATA_DIR": ...,
    "DREAM_VERSION": ..., "GPU_BACKEND": ..., "HOOK_NAME": ...,
}
proc = subprocess.Popen(..., env=hook_env, ...)

An extension author who controls setup.sh can read $AGENT_API_KEY or $DREAM_AGENT_KEY from the environment and exfiltrate them.

Platform Analysis

• macOS: Affected — host agent runs natively; its environment contains launchd-injected secrets.
• Linux: Affected — host agent runs as a systemd service; environment includes secrets passed via EnvironmentFile=.
• Windows/WSL2: Affected — same environment inheritance applies in the WSL2 context.

Reproduction

1. Create a user extension with a setup.sh that writes env > /tmp/leaked.txt.
2. Install the extension via POST /api/extensions/{service_id}/install.
3. Check /tmp/leaked.txt — it will contain AGENT_API_KEY and other host-agent secrets.

Impact

A malicious or compromised extension package in the extensions library could exfiltrate the dashboard API key and host agent API key during install. This allows the extension to make authenticated calls to the host agent API (container start/stop, model activation, file deletion) without operator knowledge. Risk is highest in multi-user or cloud-hosted DreamServer deployments.

Suggested Approach

Pass the same minimal allowlist env dict used in _execute_hook to the subprocess.run call in _run_install. The INSTALL_DIR and GPU_BACKEND are already passed as positional argv, so hook scripts do not need them from the environment. This harmonises both install paths with the same security posture.

---

Filed by automated Python auditor after full-sweep review of Python 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

FIXED by PR Light-Heart-Labs#905.

Evidence — env allowlist enforced in deployed binary

After fresh install, source-level inspection of /home/rosenrot/dream-server/bin/dream-host-agent.py (this is the actually-deployed file, post-install). Programmatic check:

import inspect, importlib.util, sys
spec = importlib.util.spec_from_file_location('dha', '/home/rosenrot/dream-server/bin/dream-host-agent.py')
mod = importlib.util.module_from_spec(spec)
sys.modules['dha'] = mod
spec.loader.exec_module(mod)
src = inspect.getsource(mod.AgentHandler._handle_install)

for secret in ['AGENT_API_KEY', 'DREAM_AGENT_KEY', 'DASHBOARD_API_KEY']:
    assert secret not in src, f'LEAK: {secret}'

for k in ['PATH','HOME','SERVICE_ID','SERVICE_PORT','SERVICE_DATA_DIR','DREAM_VERSION','GPU_BACKEND','HOOK_NAME']:
    assert f'"{k}"' in src, f'MISSING: {k}'

Result on the deployed binary:

OK: AGENT_API_KEY not in _handle_install
OK: DREAM_AGENT_KEY not in _handle_install
OK: DASHBOARD_API_KEY not in _handle_install
OK: PATH
OK: HOME
OK: SERVICE_ID
OK: SERVICE_PORT
OK: SERVICE_DATA_DIR
OK: DREAM_VERSION
OK: GPU_BACKEND
OK: HOOK_NAME

All three secret keys named in this issue (AGENT_API_KEY, DREAM_AGENT_KEY, DASHBOARD_API_KEY) are absent from _handle_install. All 8 allowlist keys are present. The fix matches the issue's "Suggested approach" exactly.

Subprocess.run env= verification

Both subprocess.run sites in _handle_install pass env=hook_env:

$ grep -n "env=hook_env" bin/dream-host-agent.py
953:                cwd=str(ext_dir), env=hook_env,
1035:                            cwd=str(ext_dir), env=hook_env,

Neither inherits os.environ (which would include the host-agent secrets). The hook env is constructed from the allowlist + the SERVICE_* / HOOK_NAME runtime values.

Test coverage

PR Light-Heart-Labs#905 ships 4 regression tests in test_host_agent.py:

• TestInstallHookEnvAllowlist::test_setup_hook_subprocess_run_passes_env_kwarg — asserts "env=hook_env" substring in _handle_install source
• TestInstallHookEnvAllowlist::test_setup_hook_env_excludes_host_agent_secrets — asserts the 3 secret names are NOT in the source
• TestInstallHookEnvAllowlist::test_setup_hook_env_contains_allowlist_keys — asserts all 8 allowlist keys ARE in the source
• TestInstallHookEnvAllowlist::test_setup_hook_uses_resolve_hook_with_post_install — locks in the new _resolve_hook(..., 'post_install') shape (also addresses bug: _handle_install uses legacy _resolve_setup_hook — silently skips hooks.post_install defined in new hooks schema #313)

$ pytest tests/test_host_agent.py::TestInstallHookEnvAllowlist -q
....                                                                     [100%]
4 passed in <1s

All 4 tests pass on the integration branch under pytest 9 + pytest-asyncio.

These are source-inspection tests rather than dynamic-execution tests, which the PR description correctly justifies: the subprocess.run call lives inside a nested closure on a daemon thread, which is fragile to mock dynamically. Source inspection is deterministic and catches the regression class this issue identifies.

What was NOT tested

• Did not actually install an extension with a post_install hook and verify the subprocess receives only the allowlist env at runtime. The source-level test is sufficient to lock in the file state, but a true e2e test against a running hook would be a stronger signal — it just requires fixture setup that the timebox didn't allow.

Pre-requisite worth flagging

Same as the other host-agent PR comments in this batch: the installer didn't restart dream-host-agent.service after rewriting the binary (see #334 filed during this test pass). The deployed binary on disk is correct; the running process before manual restart was the OLD host-agent inheriting the full env. Critical for any QA checking this fix at runtime — the file looks fixed but the running daemon may still be the old code.

---

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

[yasinBursali]

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