The ShrekOS Isolation Model: Bench and Capabilities
ShrekOS introduces a novel approach to running untrusted workloads, encapsulated within a concept called a 'Bench.' This model is designed to provide a secure execution environment by strictly limiting what an agent, or any untrusted job, can access. The core principle is 'deny by default.' A Bench starts with absolutely no files visible and no network access. Any capability beyond this bare minimum is explicitly granted, narrowly defined, and revocable. This post details the visual representation of this system, building upon the arguments presented in earlier discussions about agent capabilities.
Four Foundational Rules for Secure Execution
The ShrekOS Bench model is built upon four critical rules that enforce strict security boundaries:
1. Deny by Default
The fundamental security posture of ShrekOS is to deny all access by default. When a Bench is initialized, it is an empty sandbox. It possesses no pre-existing files it can read or write, and no network connections it can establish. Every subsequent permission is an exception, opened deliberately and with careful consideration. This ensures that the workload operates within the smallest possible attack surface.
2. A Grant is a Pinned Object, Not a Path
A key innovation in ShrekOS's capability management is how it handles grants. When a directory is granted to a Bench, the system does not simply provide a path. Instead, it pins the actual inode of the directory. This pinned inode is then mounted within the Bench, crucially with the 'noexec' flag enforced. This prevents malicious actors from manipulating symbolic links to redirect access to unintended locations or directly executing files within the granted directory. The grant is tied to the specific data structure on disk, not a potentially mutable filesystem path.
3. Capabilities are Granted One at a Time
To maintain granular control, ShrekOS grants capabilities to a Bench sequentially. This means that only one specific capability, such as access to a particular folder or a specific hostname, is provided at any given moment. This contrasts with systems that might grant broad permissions or multiple capabilities simultaneously. The sequential granting process allows for tighter monitoring and easier revocation if a capability is misused.
4. Revocability is Key
Every capability granted to a Bench is designed to be revocable. This means that if an agent or workload exhibits suspicious behavior or if its operational needs change, its permissions can be withdrawn. This revocability is essential for dynamic security management, allowing the system to adapt to evolving threats or changing operational requirements without needing to restart the entire workload or the Bench itself. The system can dynamically revoke access to a folder or hostname as needed.
Visualizing the ShrekOS Architecture
To understand how these rules translate into practice, consider two primary diagrams. The first illustrates the basic setup of a Bench, emphasizing its initial state and the nature of granted capabilities. The second diagram focuses on the specific scenario of granting an agent exactly one folder and one hostname, showcasing the minimal, precise nature of these grants.
Diagram 1: The Isolated Bench
The first diagram depicts a single Bench. It is visually represented as an isolated container. Inside this container, there are no visible file system icons or network connection symbols initially. Arrows pointing into the Bench originate from an external 'Capability Manager' or 'Granting Service.' These arrows are specific and labeled, for example, 'Grant: /data/input (inode X, noexec)' or 'Grant: api.example.com (IP Y).' The 'noexec' attribute is prominently displayed next to file system grants. This visual emphasizes the 'deny by default' rule and the pinned, specific nature of granted capabilities. The agent process runs within this tightly controlled environment.
Diagram 2: Single Folder and Hostname Grant
The second diagram zooms in on a specific, common use case: granting an agent access to a single input folder and a single remote hostname. The Bench is shown containing the agent process. A single, clearly demarcated folder icon is present within the Bench's file system view, labeled something like '/input'. This folder is visually linked to an external storage location, but the connection is shown as a direct inode mount, not a general directory mount. Crucially, it is marked with 'noexec.' Similarly, a single network connection icon is shown, labeled with a specific hostname, e.g., 'api.example.com.' This connection is depicted as a direct, narrowly defined pathway, not a general network interface. This diagram powerfully illustrates the principle of granting minimal, precisely defined resources, ensuring the agent can perform its task without extraneous access. The isolation is stark: no other folders, no other hostnames are visible or accessible.
Implications for Untrusted Workloads
This architectural design has profound implications for how untrusted code can be safely executed. By adhering to the four rules—deny by default, pinned grants, single-capability grants, and revocability—ShrekOS significantly reduces the potential for privilege escalation and lateral movement. An agent confined to a single folder and a single hostname, with no execution rights in that folder and no general network access, presents a vastly diminished threat compared to traditional sandboxing methods. The workload is effectively given just enough rope to do its job, but not enough to hang itself or compromise the underlying system. This model is particularly relevant for scenarios involving third-party code execution, CI/CD pipelines, or any environment where the integrity of the workload cannot be fully guaranteed.
The design is elegant in its simplicity and robust in its security. It moves beyond superficial sandboxing to a model of capability-based security where permissions are explicit, minimal, and managed with precision. If you are building systems that need to execute untrusted code, understanding this model is critical for robust security design.