Designing Secure and Isolated Execution Environments for Untrusted Workloads
This article outlines the architectural principles behind "ShrekOS," a system designed to run untrusted agent workloads with extreme isolation. It focuses on a "deny by default" security model, granting capabilities narrowly and revocably, and preventing data exfiltration by separating network access from secret access. The core idea is a disposable execution environment, called a Bench, that starts with no network or files and is granted only specific, pinned resources.
Read original on Dev.to #architectureThe "ShrekOS" architecture introduces the concept of a Bench, a disposable, highly isolated execution environment for untrusted workloads or agents. The primary goal is to allow agents to perform real work while minimizing their access to the host system and external networks. This design is crucial for scenarios requiring strong security boundaries, such as running third-party code, build processes, or sensitive data transformations where compromise of one workload must not affect others or leak credentials.
Core Principles of Bench Isolation
- Deny by default: A Bench starts with no visible files or network access. All capabilities are explicitly granted.
- Pinned object grants: Directory grants are pinned inodes, not paths, preventing symlink attacks or execution from host mounts.
- Sealed, pinned egress: Network access is restricted to named, pre-resolved destinations (e.g., `deb.debian.org`), with no direct DNS access or arbitrary internet connectivity.
- Separation of secrets and egress: A Bench can never access both a secret (e.g., an API token) and arbitrary network destinations simultaneously. Credentialed calls are brokered outside the Bench.
This architectural approach prioritizes a fail-closed security posture, where any ungranted access is implicitly denied. The disposability of the Bench further enhances security by ensuring that any state modified by an untrusted agent is discarded after execution, limiting the long-term impact of a breach.
Egress Control Flow
flowchart TB BN["Bench (default: no net)"] --> P{"sealed profile (pinned)"} P -->|apt| DEB["deb.debian.org"] P -->|pip| PY["PyPI"] P -->|model| BR["broker to provider"] BN -.->|blocked| H["host-local"]Design Implication
Implementing "deny by default" requires a robust mechanism for capability-based security. Instead of blacklisting, systems should whitelist only essential resources. This often involves kernel-level isolation technologies (like namespaces, cgroups, seccomp) combined with application-level proxies or brokers for controlled resource access. The broker pattern for secrets is a classic example of this.