# Round 11 review — GLM management-boundary pass (revision 17, sections 1, 2, 3, 15, 16 + labelled context)

Reviewed the provided revision-17 excerpts directly; no runtime verification performed or claimed.

## Finding 1 — Section 16, "Cloudflare Tunnel endpoint" (cross-ref: section 3 placement rules; section 16 transport acceptance cases)

**Severity: Low**

The section requires protected files, parent directories, registrations, and provisioning paths for the tunnel and push-submission *credentials*, and applies protected-placement/signed-generation/update rules to Remozio's own bundles and to the new setup controller — but states no placement or update-path requirement for the third-party `cloudflared` executable itself, which runs under the same dedicated transport account that holds both credentials. Section 3's "root-launched code must resist replacement" sentence is scoped to Remozio's trusted bundles, and the acceptance list tests same-user replacement of the credential *files*, not the binary that reads them.

**Concrete failure:** an unprivileged process running as the interactive administrator replaces a `cloudflared` binary installed on an admin-writable path (the exact `/usr/local`-style pitfall section 3 calls out). launchd restarts it as the transport account; the replaced binary reads the tunnel run credential and Mac push-submission credential from dedicated-account-private storage — storage the plan otherwise correctly protects — and exfiltrates both. The attacker then operates a competing connector for the configured hostname (persistent endpoint impersonation, metadata exposure, selective DoS) and can spam mapped wake notifications. Severity is bounded: end-to-end payload encryption, pinned identities, and gateway recipient mapping still prevent request forgery or decryption.

**Minimal correction:** one sentence in this subsection extending the existing custody requirement to the cloudflared executable and any binary run under the transport account — root-owned, non-user/admin-group-writable file, containing directories, registration, and update path (no self-update into user-writable locations) — and one added acceptance case: same-user replacement of that executable.

**UX impact:** none. Setup-time file placement only; no new prompts, biometrics, enrollment, or manual steps. Consistent with the binding UX constraints.

## Disposition verification (round 10 / Opus 1)

Checked against the revision-17 text: the setup controller appears in the section 3 component inventory and the section 17 release manifest; management token custody is root-only, outside transport and interactive-user storage; operations are administrator-authorized, typed, and resource-bound with no listener or generic proxy; phone, push, and transport credentials are explicitly barred from invoking them; Cloudflare scoping granularity is a recorded feasibility obligation with disclosed-approval fallback; recurring credential entry or authorization prompts remain a consultation blocker. No approval-flow, biometric, pairing, or remote-functionality change appears in the scoped sections. The disposition's description of the revision-17 correction is accurate.

## Conclusion

SUBSTANTIVE FINDINGS REMAIN (one low-severity, one-line correction; no UX cost).