Homer
96f269dadb
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>
48 lines
2.4 KiB
Desktop File
48 lines
2.4 KiB
Desktop File
# Runs deploy/update.sh when the web interface asks for it.
|
|
#
|
|
# install.sh substitutes __PREFIX__, __SERVICE_USER__ and __UPDATE_BRANCH__ and
|
|
# writes the result to /etc/systemd/system/lembas-update.service.
|
|
#
|
|
# **What this grants.** Installing it means anybody who can administer the web
|
|
# interface can deploy whatever is on the configured branch, as root, and
|
|
# restart the service. That is the point of it, and it is why it is opt-in and
|
|
# why the installer says so out loud rather than doing it by default.
|
|
#
|
|
# **What it deliberately does not grant.** The request file carries nothing that
|
|
# reaches this command line: no ref, no branch, no channel, no arguments. Both
|
|
# are baked in below from the installer's environment, so pressing the button is
|
|
# "deploy the channel this host was configured with" and can never be "deploy
|
|
# something else". Nothing reads the file's *contents* either -- `ExecStartPre`
|
|
# deletes it and the `.path` unit only ever tested that it exists.
|
|
#
|
|
# And root runs a script **root owns**. See ExecStart.
|
|
|
|
[Unit]
|
|
Description=Apply a requested LLeMbas update
|
|
# Not `After=lembas.service`: this restarts it, and an ordering dependency on
|
|
# the thing being restarted is how a one-shot ends up waiting for itself.
|
|
|
|
[Service]
|
|
Type=oneshot
|
|
# Deleted first, always. The path unit re-arms on the file existing, so leaving
|
|
# it in place would run this again the moment the service came back -- an
|
|
# update loop with no obvious cause. `-` so a failure to delete does not stop
|
|
# the update, and `ExecStartPre` so it happens even if the script itself fails.
|
|
ExecStartPre=-/usr/bin/rm -f __PREFIX__/data/update-requested
|
|
Environment=SERVICE_USER=__SERVICE_USER__
|
|
Environment=PREFIX=__PREFIX__
|
|
Environment=LEMBAS_BRANCH=__UPDATE_BRANCH__
|
|
Environment=LEMBAS_CHANNEL=__UPDATE_CHANNEL__
|
|
# **Not** `__PREFIX__/app/deploy/update.sh`. That path is inside the checkout and
|
|
# owned by the unprivileged service account, so root would have been executing a
|
|
# file that account could rewrite -- and that an update could replace, since a
|
|
# pull runs as that account and root runs whatever it fetched on the next press.
|
|
# `install.sh` puts a root-owned copy here instead. Improving the script means
|
|
# re-running the installer, which is the right cost.
|
|
ExecStart=/bin/bash __UPDATE_HELPER__
|
|
# The script's own failure path prints the journal and exits non-zero, which is
|
|
# what makes `systemctl status lembas-update` say what went wrong.
|
|
StandardOutput=journal
|
|
StandardError=journal
|
|
TimeoutStartSec=600
|