[sec-check] Homelab applier puts freshly generated Console and Grafana passwords on a command line other users can read #510

Summary: When a Bluefin Server homelab cluster starts for the first time, a small program on the node creates a few passwords and tokens for the built-in web tools (the KubeStellar Console's admin password, its session-signing secret, Grafana's admin password, the database password). Today those freshly generated values are handed to the cluster tool as command-line arguments, and on Linux any user logged into the machine can see every running program's arguments. A non-admin user with a shell on the node (the "SSH owner" account that a combined Home + Homelab install creates on purpose, without admin rights) could watch for that moment and copy the Console admin password or signing secret, which are never rotated. The fix is to hand the values over through private files instead of arguments.

Security Finding

Severity: low
Type: unsafe-pattern (secret material on a process command line)

files/homelab/sysext/bluefin-homelab-apply, function apply_secrets(): values generated by @random and @htpasswd:<user> entries of a component's secrets list — and any plain literal — are passed to kubectl create secret generic as --from-literal=<key>=<value> arguments:

• kubestellar-console-jwt jwt-secret=@random
• kubestellar-console-bootstrap bootstrap-token=@random
• kubestellar-console-login .htpasswd=@htpasswd:admin (the {SHA} line and the clear-text password key)
• grafana-admin admin-password=@random
• postgres-postgresql postgres-password=@random

The image mounts /proc without hidepid (no hidepid, ProtectProc= or ProcSubset= anywhere under files/, elements/, include/), so /proc/<pid>/cmdline of the root-owned kubectl is world-readable while it runs. The applier already treats these values as sensitive everywhere else (never logged, console issue file 0600, @file inputs read from 0600 operator files), so the argv exposure is the one gap.

Impact

Preconditions: an unprivileged local account on the node and presence during the one-time first apply (the values are generated once and never rotated, apply_secrets skips an existing Secret). docs/skills/usb-installer.md ("Optional cluster composition") documents exactly such an account: the SSH owner of a combined Home + Homelab install, who deliberately gets no sudo and no admin kubeconfig and is a separate identity from the Console administrator. A loop reading /proc/*/cmdline during the first boot captures:

• the Console admin login password → full Console access as the built-in admin (dev-user), bypassing the identity separation the composition promises;
• the Console JWT signing secret → forged sessions for the Console's lifetime;
• the Grafana admin password and the KubeFlex Postgres password when those components are enabled.

Not reachable from pods (no hostPID workload in the shipped manifests) or from the network. Rated low because of the local-account and timing preconditions.

Recommendation

Keep every literal off the command line: write it with printf (a builtin) into a 0600 file under the applier's private mktemp -d work directory and pass --from-file=<key>=<path> for it, exactly as the @file/@optfile entries already do, then remove the files. kubectl refuses --from-env-file together with --from-file, so --from-file for everything is the one form that keeps mixed lines working. The accompanying pull request does this and updates tests/unit/bluefin-homelab-apply_test.bats so the stub records the file-backed values and asserts no --from-literal is ever passed.

• apply_secrets() builds Secrets from --from-file only; generated values never appear in argv
• bats coverage asserts it

Filed by sec-check agent (ACMM L4/L5 — hold-gated mode)

— hive: agent=sec-check backend=copilot model=claude-fable-5.1 copilot=1.0.88