Sandboxing, Broker Architectures and Isolation Assurance — DedSec Project
Sandboxing, Broker Architectures and Isolation Assurance Sandboxes are systems of constrained authority, not magic boxes. This module explains policy surfaces, broker patterns, escape…
Sandboxes are systems of constrained authority, not magic boxes. This module explains policy surfaces, broker patterns, escape classes, verification strategy and how to reason about isolation guarantees.
Learning objectives
By the end of this module you should be able to:
- Explain sandbox threat models and identify its most important trust boundary, state transition, and evidence source.
- Explain deny-by-default policy and identify its most important trust boundary, state transition, and evidence source.
- Explain syscall and filesystem mediation and identify its most important trust boundary, state transition, and evidence source.
- Explain brokers and privileged helpers and identify its most important trust boundary, state transition, and evidence source.
- Explain namespace and job-object style isolation and identify its most important trust boundary, state transition, and evidence source.
- Explain seccomp, MAC and platform policy concepts and identify its most important trust boundary, state transition, and evidence source.
Deep concepts
1. sandbox threat models
A sandbox reduces the impact of compromised or untrusted code by limiting reachable resources and operations. State what attacker capability the sandbox assumes and which assets remain outside its boundary; otherwise “sandboxed” becomes an undefined security claim.
2. deny-by-default policy
Sandbox policy is easier to reason about when access starts denied and narrowly grants required capabilities. Each exception should have an owner, reason, resource scope, and regression test so compatibility changes do not silently expand authority.
3. syscall and filesystem mediation
System calls and filesystem access are common sandbox boundaries because they connect code to kernel-managed resources. Mediation should use stable object identity where possible and account for path resolution, links, mounts, namespaces, and inherited descriptors.
4. brokers and privileged helpers
Privileged helpers are intentional escape hatches from a sandbox, so they deserve a smaller and more rigorously validated API than ordinary application code. Pass caller identity and resource context explicitly and reject requests the helper cannot authorize locally.
5. namespaces and job-object isolation
Namespaces, cgroups, job objects, tokens, and similar primitives isolate different resource dimensions rather than creating one universal boundary. Verify which resources are actually separated—processes, mounts, network, IPC, users, devices, or quotas—and which are still shared.
6. seccomp, MAC and platform policy
Seccomp and mandatory-access-control policy constrain behavior after ordinary discretionary permissions are applied. Policies should be generated from understood requirements, tested for fail-closed behavior, and monitored for denials that indicate drift or missing assumptions.
7. escape classes without weaponization
Sandbox escapes usually involve a reachable privileged interface, kernel/runtime bug, policy gap, parser bug, or confused deputy. Defensive analysis should classify the boundary failure and reproduce only on a toy/owned target instead of turning the finding into a reusable escape chain.
8. assurance, regression and telemetry
Isolation requires evidence over time: policy versions, broker decisions, denied operations, privileged transitions, and regression tests after runtime updates. A sandbox that cannot be observed or retested is difficult to trust during incident response.
Authorized lab sequence
Lab 1 — Build a toy process with an allowlist of file operations and document what is intentionally denied.
Lab 2 — Compare two container/sandbox configurations by capabilities, mounts, network access and process visibility.
Lab 3 — Write regression tests that prove a sandboxed component cannot access three lab-only resources outside its policy.
Knowledge checks
Answer these without looking at the notes:
Next modules
Recommended related modules: 041, 074, 075, 094, 095, 112. From the main menu, choose Search lessons to find related sections across the full guide.