Skip to main content

Threat Model

This threat model is the Phase 7 baseline. It focuses on StacyVM as a self-hosted sandbox control plane with local providers, live previews, SDK access, and an admin dashboard.

Assets

  • Host access to Docker, KVM, Firecracker, PRoot, and filesystem paths.
  • Sandbox filesystem contents and user workspaces.
  • API and admin API keys.
  • SQLite database, audit logs, quotas, templates, environments, and registry metadata.
  • Live-preview traffic and routing metadata.
  • Registry credentials and build artifacts.

Trust Boundaries

Primary Threats

Phase 7 Security Objectives

  • Make production misconfiguration visible through stacyvm doctor --production.
  • Remove ambiguous command execution semantics before recommending public workloads.
  • Increase file API path traversal coverage. Done for manager scoping and provider boundaries.
  • Extend persisted audit beyond admin routes. Done for sandbox lifecycle, exec, and file operations.
  • Convert runtime conformance docs into repeatable host checks. Done with scripts/certify-runtime.sh.

Non-Goals For Phase 7

  • Multi-worker scheduling.
  • Full OIDC/SSO implementation.
  • Postgres store.
  • Enterprise RBAC.
Those belonged to later production stages after the single-node release candidate was hardened.

Phase 14 Security Additions

  • OIDC/JWT RS256 Bearer token auth with JWKS and configurable issuer, audience, and group-to-role mapping.
  • RBAC roles: viewer, operator, admin, tenant_admin with scoped permission sets.
  • Tenant/project model: resource isolation per tenant, per-tenant audit export.
  • Policy controls: image, provider, and network allow-deny enforcement at spawn time.
  • Centralized worker token issuance: workers obtain signed tokens from the control plane without holding the signing key.
  • Sandbox tenant scoping: List and Get enforce tenant boundaries for OIDC-authenticated callers.