H-001: Unverified Script Execution in Dockerfile

[shrwnsan]

Severity: High

Location

Dockerfile:48-56, 83-85, 89-95, 115-116, 132

Issue

Multiple third-party scripts are piped directly to shell without hash verification:

• GitHub CLI keyring (line 48)
• uv installer (line 83)
• NVM installer (line 91)
• SDKMAN installer (line 115)
• oh-my-zsh installer (line 132)

Impact

Supply chain compromise if any of these distribution channels are compromised.

Remediation

1. Download script to temporary file first
2. Verify checksum against known good value
3. Only execute after verification

Reference

See docs/eval-001-security-review.md for full review.

---

🤖 Generated by Claude Code - GLM 4.7

[shrwnsan]

Review Assessment

Recommendation: Document trade-offs + selective verification for critical installers

This is a valid security concern, but full remediation has significant maintenance costs that may not align with the project's "YOLO-mode" philosophy.

Trade-off Analysis

Pros of full checksum verification:

• ✅ Protects against supply chain compromise
• ✅ Increases build reproducibility
• ✅ Follows security best practices

Cons of full checksum verification:

• ❌ High maintenance burden (updating checksums on every tool release)
• ❌ Most tools (NVM, SDKMAN, oh-my-zsh) don't publish checksums in automatable locations
• ❌ Breaks automatic updates, requiring manual intervention
• ❌ Increases Dockerfile complexity significantly

Context

AgentBox is designed for ephemeral, isolated AI agent execution. The threat model already accepts some risk in favor of usability and maintenance simplicity. The eval notes this: "Project designed for YOLO-mode AI agent execution - threat model reflects this purpose."

---

Recommended Approach: Pragmatic Mitigation

Option 1: Document the trade-off (Minimum viable)

Add a comment block in the Dockerfile explaining the decision:

# Security Note: The following installers are executed without checksum verification.
# This is a conscious trade-off between security and maintainability.
# 
# Risk: Supply chain compromise if distribution channels are compromised
# Mitigation: Container isolation limits blast radius to ephemeral environments
#
# For high-security environments, consider:
# 1. Building a hardened image with pinned, verified versions
# 2. Using an air-gapped registry with approved images
# 3. Scanning the resulting image with tools like Trivy or Grype

Option 2: Selective verification for critical installers (Recommended)

Verify only the most critical installer that runs most frequently: uv

# Verify uv installer (critical Python package manager)
RUN curl -fsSL https://astral.sh/uv/install.sh -o /tmp/uv-install.sh && \\
    echo "CHECKSUM_HERE /tmp/uv-install.sh" | sha256sum -c - && \\
    sh /tmp/uv-install.sh && \\
    rm /tmp/uv-install.sh

# Note: Other installers (NVM, SDKMAN, oh-my-zsh) remain unverified
# due to maintenance cost vs. threat model trade-off

To get the checksum:

curl -fsSL https://astral.sh/uv/install.sh | sha256sum

Option 3: Version pinning (Alternative)

Pin specific versions where possible:

# Pin NVM version
RUN curl -o- https://raw.githubusercontent.com/nvm-sh/nvm/v0.39.7/install.sh | bash

# Pin oh-my-zsh commit
RUN sh -c "$(curl -fsSL https://raw.githubusercontent.com/ohmyzsh/ohmyzsh/master/tools/install.sh)" "" --unattended

This doesn't verify integrity but provides some protection against malicious updates.

---

My Recommendation

Implement Option 1 (document) + Option 2 (verify uv only). This provides:

• Transparency about the security trade-off
• Protection for the most critical component
• Reasonable maintenance burden
• Guidance for users with stricter requirements

---

Reviewed and generated by: Warp - Claude Sonnet 4.5