Priority: P3 (Low) · Follow-up from #17 · area: deploy/ops
Context
#17 added a sha256 gate to `deploy/lightsail/redeploy.sh`: the locally-built
`mir-signal` digest is pinned and verified on the relay box before `install`
copies it to root-owned `/usr/local/bin`. That closes the "swap the artifact in
shared /tmp" window almost entirely.
Residual gap
A small TOCTOU window remains: the remote does
```sh
GOT_SHA="$(sha256sum /tmp/mir-signal | awk '{print $1}')" # check
...verify...
install -m 0755 /tmp/mir-signal /usr/local/bin/mir-signal # use
```
Because `/tmp` is world-writable, a local user on the box could in principle swap
`/tmp/mir-signal` between the `sha256sum` check and the `install` (check-then-use
on a shared path). Exploiting it requires a local account on the relay host plus
winning a sub-millisecond race, so severity is low — but it is structurally
avoidable.
Suggested fix
Eliminate the shared-path window: copy the uploaded artifact into a root-only
staging path first, verify it there, and `install` from that verified copy — so
the bytes that are hashed are the exact bytes that get installed, on a path no
unprivileged user can write. e.g.
```sh
install -m 0700 /tmp/mir-signal /root/.mir-signal.staged # into root-only dir
GOT_SHA="$(sha256sum /root/.mir-signal.staged | awk '{print $1}')"
[ "$EXPECT_SHA" = "$GOT_SHA" ] || { echo "FATAL: checksum mismatch" >&2; exit 1; }
install -m 0755 /root/.mir-signal.staged /usr/local/bin/mir-signal
rm -f /root/.mir-signal.staged
```
Out of scope
- The deploy still trusts the operator's local build (no reproducible/signed
release for `mir-signal` yet) — tracked separately.
Priority: P3 (Low) · Follow-up from #17 · area: deploy/ops
Context
#17 added a sha256 gate to `deploy/lightsail/redeploy.sh`: the locally-built
`mir-signal` digest is pinned and verified on the relay box before `install`
copies it to root-owned `/usr/local/bin`. That closes the "swap the artifact in
shared /tmp" window almost entirely.
Residual gap
A small TOCTOU window remains: the remote does
```sh
GOT_SHA="$(sha256sum /tmp/mir-signal | awk '{print $1}')" # check
...verify...
install -m 0755 /tmp/mir-signal /usr/local/bin/mir-signal # use
```
Because `/tmp` is world-writable, a local user on the box could in principle swap
`/tmp/mir-signal` between the `sha256sum` check and the `install` (check-then-use
on a shared path). Exploiting it requires a local account on the relay host plus
winning a sub-millisecond race, so severity is low — but it is structurally
avoidable.
Suggested fix
Eliminate the shared-path window: copy the uploaded artifact into a root-only
staging path first, verify it there, and `install` from that verified copy — so
the bytes that are hashed are the exact bytes that get installed, on a path no
unprivileged user can write. e.g.
```sh
install -m 0700 /tmp/mir-signal /root/.mir-signal.staged # into root-only dir
GOT_SHA="$(sha256sum /root/.mir-signal.staged | awk '{print $1}')"
[ "$EXPECT_SHA" = "$GOT_SHA" ] || { echo "FATAL: checksum mismatch" >&2; exit 1; }
install -m 0755 /root/.mir-signal.staged /usr/local/bin/mir-signal
rm -f /root/.mir-signal.staged
```
Out of scope
release for `mir-signal` yet) — tracked separately.