security: Bash guardrail has no deny pattern for sudo writes to the guardrail registration; docs claim it cannot be rewritten (CSO 2026-09-29 #5) #3105

Summary

developer ALL=(ALL) NOPASSWD:ALL (base-image Dockerfile L198-199) is a documented design choice, and docs/memory/architecture/security.md L134 already states root ownership only prevents accidental rewrites. The guardrail subsystem's own text says the opposite — L133 "the file cannot be rewritten", requirements security.md §28.1 "agents cannot opt out" — and the ent#345 fix closed only the unprivileged path: path_deny (/etc/claude-code/*, /opt/trinity/*) is consulted by file-guardrail.py (Edit/Write) only, while bash_deny in docker/base-image/hooks/guardrails-baseline.json — which regex-matches the full command string and so can see it — has no sudo/registration pattern. startup.sh L26-36 checks writability once at boot and logs "registration verified". One sudo write to /etc/claude-code/managed-settings.json or /opt/trinity/hooks/* disables every hook for the container's remaining life with no log line.

Narrowing sudoers is not viable (DAC_OVERRIDE / sudo apt are intended), so the hook is the cheap control. A regex deny list remains a speed bump against a determined adversary — this is defense in depth, not a boundary.

Acceptance criteria

• bash_deny gains a pattern for sudo writes touching /etc/claude-code, /opt/trinity or /etc/sudoers, and one for interactive root shells (sudo -i/-s/su/bash).
• The tracked /health follow-up (§28.2.1) stats the registration per request or per execution, not per boot.
• security.md L133 and requirements §28.1 are reconciled with L134 ("cannot be rewritten without sudo").
• test_ent345_guardrail_registration.py (or a sibling) asserts the new deny patterns match the obvious spellings.

Evidence

docs/security-reports/cso-2026-09-29.md Finding 5 (ASI05).