DedSec Project

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:

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

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.