Boundaries that were supposed to hold

The security pass. Six findings, none reachable by visiting the site and
every one a boundary this codebase says it keeps.

A subagent is pinned to a list of read-only commands, in every mode,
unattended, with no card anybody could approve -- and `find *` was on it.
find writes files with -fprintf, runs programs with -exec and removes them
with -delete, and none of that needs a character the metacharacter guard
refuses. A page the model had just read could ask for a helper and get a
key into authorized_keys, from Plan mode, which promises to change
nothing. Refused in `subject()` rather than trimmed from the list: a
pattern cannot say "and no dangerous flags", and "this one looks
read-only" is exactly what put find there.

The loopback guard missed `0.0.0.0`, which is not is_loopback but does
connect to localhost -- so it answered a *decided* False and skipped the
DNS half too. The one spelling of "this machine" that walked past a guard
whose whole job is that sentence.

Twice in the update helper, which is the one place this deliberately
crosses a privilege boundary: root ran a script the service account owns,
and root sourced a file that account can replace. Either turns a
compromise of the web application into root. The first needed no
compromise at all -- a pull happens as the service user and root runs
whatever it fetched, so control of the branch was control of root. The
old test asserted that exact ExecStart line and had pinned it in place.

Push endpoints skipped check_url, the only outbound request that did. And
a chat could be filed in another account's folder, which hands over its
system prompt -- `_new_chat` resolved the folder, discarded it when it was
not the caller's, and stored the raw id anyway.

An existing helper install keeps the old wiring until install.sh is
re-run; update.sh now says so when it finds itself inside the checkout.

Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>

deploy/install.sh

@@ -165,12 +165,34 @@ echo "== update helper =="
 # is-enabled`, because that would be a subprocess on every page render to answer
 # a question that changes once.
 UPDATE_MARKER="$PREFIX/data/.update-helper"
+# Where root's copy of the update script lives, and why it is a copy.
+#
+# The unit runs as root. Pointing its ExecStart at `$PREFIX/app/deploy/update.sh`
+# meant root executing a file owned by the **unprivileged service account** --
+# so anything able to write as that account could rewrite the script, create the
+# request file it also owns, and be root. That is the whole privilege boundary
+# the helper exists to keep, defeated by a `chown`.
+#
+# The second path is worse because it needs no compromise at all: an update
+# pulls new code *as the service user*, and root then runs whatever
+# `deploy/update.sh` that pull contained. Control of the branch would have been
+# control of root.
+#
+# So root runs a copy it owns, installed here, by an administrator, deliberately.
+# The cost is that improving `update.sh` needs `install.sh` re-run -- which is
+# the correct trade: root should not execute a script that arrived over the
+# network a moment ago.
+UPDATE_HELPER_DIR="/usr/local/lib/lembas"
+UPDATE_HELPER="$UPDATE_HELPER_DIR/update.sh"
 if [[ "$INSTALL_UPDATE_HELPER" == "1" ]]; then
+  sudo mkdir -p "$UPDATE_HELPER_DIR"
+  sudo install -o root -g root -m 755 "$HERE/update.sh" "$UPDATE_HELPER"
   for unit in lembas-update.path lembas-update.service; do
     sed -e "s|__PREFIX__|$PREFIX|g" \
         -e "s|__SERVICE_USER__|$SERVICE_USER|g" \
         -e "s|__UPDATE_BRANCH__|$BRANCH|g" \
         -e "s|__UPDATE_CHANNEL__|$CHANNEL|g" \
+        -e "s|__UPDATE_HELPER__|$UPDATE_HELPER|g" \
         "$HERE/$unit" | sudo tee "/etc/systemd/system/$unit" >/dev/null
   done
   sudo systemctl daemon-reload
@@ -187,7 +209,8 @@ else
   # the manual one, which is the honest degradation.
   sudo systemctl disable --now lembas-update.path 2>/dev/null || true
   sudo rm -f /etc/systemd/system/lembas-update.path \
-             /etc/systemd/system/lembas-update.service "$UPDATE_MARKER"
+             /etc/systemd/system/lembas-update.service "$UPDATE_MARKER" \
+             "$UPDATE_HELPER"
   sudo systemctl daemon-reload
   echo "   not installed (INSTALL_UPDATE_HELPER=1 to allow updating from the web UI)"
 fi