[setup-security] Unpinned curl | sudo sh root install in sudo_docker_sbx_install.sh (supply-chain risk)

Summary

actions/setup/sh/sudo_docker_sbx_install.sh installs the Docker apt repository by piping a remotely-fetched, unversioned convenience script directly into a root shell: curl -fsSL (get.docker.com/redacted) | sudo REPO_ONLY=1 sh. Because the script body is fetched at run time and executed as root without any integrity verification (no pinned commit/tag, no checksum), whatever get.docker.com returns at that moment runs with full privileges on the runner. This is the classic curl | sudo sh supply-chain risk: a compromise of the upstream endpoint, a TLS/MITM downgrade, or a malicious redirect yields arbitrary root code execution inside the setup action. Sibling installers in the same directory (e.g. sudo_gvisor_install.sh) already demonstrate the hardened pattern — pinned version plus SHA-512 verification — so this script is inconsistent with the repository's own baseline.

Affected Files

File	Line(s)	Pattern
`actions/setup/sh/sudo_docker_sbx_install.sh`	15	`curl -fsSL (get.docker.com/redacted) \| sudo REPO_ONLY=1 sh`

Risk

Severity: Medium
Attack vector: An attacker who can influence the content served from (get.docker.com/redacted) (upstream compromise, CDN/DNS hijack, or an on-path TLS interception where cert validation is weakened) causes attacker-controlled shell code to be executed as root during the setup action. There is no pinning or checksum to detect substitution, and the piped-to-shell form means the code runs even if only partially downloaded.
Impact: Arbitrary root-level code execution on the GitHub Actions runner during setup — full compromise of the workflow environment, including any secrets/tokens present in the job, the ability to tamper with the AWF sandbox/firewall setup, and persistence within the runner for the remainder of the job.

Recommendation

Stop piping a remote script into a privileged shell. Prefer adding the Docker apt repository deterministically: install the pinned Docker GPG key and write the deb [signed-by=...] source line directly, then sudo apt-get update && sudo apt-get install -y docker-sbx.
If the convenience script must be used, pin it to a specific commit and verify it before execution: download to a file, compare against a checked-in SHA-256, and only then run it — never pipe curl output straight into sh. Mirror the pattern already used in sudo_gvisor_install.sh (pinned version + SHA-512 sha512sum -c).
Fetch to disk with an explicit failure on redirect/host mismatch and add the runner-guard:ignore annotation with a justification only after verification is in place, consistent with the other install scripts.

Evidence

Relevant code snippet — actions/setup/sh/sudo_docker_sbx_install.sh

echo "::group::Install docker-sbx"
# Add Docker apt repo without installing Docker Engine (already present).
curl -fsSL (get.docker.com/redacted) | sudo REPO_ONLY=1 sh
sudo apt-get install -y docker-sbx
sbx version
# Fix KVM permissions so the runner user can create microVMs.
sudo chmod 666 /dev/kvm
echo "docker-sbx installed successfully"
echo "::endgroup::"

Contrast with the hardened sibling sudo_gvisor_install.sh (pinned version + checksum verification):

URL="(storage.googleapis.com/redacted)
curl -fsSL "${URL}/runsc" -o /tmp/runsc
curl -fsSL "${URL}/runsc.sha512" -o /tmp/runsc.sha512
(cd /tmp && sha512sum -c runsc.sha512)

Generated by 🛡️ Daily action/setup/* Security Audit · copilot · opus48 · 134 AIC · ⌖ 33.3 AIC · ⊞ 10.2K · ◷

🍪 Issue Monster selected this for Copilot

I’ve identified this issue as a good candidate for automated resolution and requested assignment to the Copilot coding agent.