Linux Security / Advanced: constrained design and verified change / Lesson 13

Reason about namespaces, seccomp, and sandbox limits

Distinguish resource views, syscall filtering, authority, and the shared trust that a sandbox still requires.

About 4 min readContent reviewed 2026-10-28

On this page

Lesson goals

Explain why a namespace view is not complete resource authorization.
State the role and limits of seccomp without installing a filter.

Name the boundary each mechanism addresses

Namespaces give processes scoped views of selected resources, while credentials and capabilities govern authority under their own rules. Seccomp restricts system-call interfaces according to a filter; it does not replace a complete application or filesystem policy. Containers can combine these mechanisms but still depend on kernel and runtime trust. Do not call every container a virtual machine or assume a separate hostname means separate security authority. The lesson compares declared properties only and performs no clone, unshare, mount, filter installation, container operation, kernel query, or host inspection.

Distinguish a different view from denied authority

The first program models two views of a resource label while retaining an independent administration flag. A changed view does not set that flag to false. This is not a Linux namespace implementation; it illustrates why isolation claims need more than visual separation. Actual user, mount, PID, network, and other namespaces have different scopes and interactions. A real design must review mapped identities, inherited descriptors, mounted resources, and runtime grants. Preserve which namespace type matters rather than using one generic isolated=true value as proof of containment.

python Compare synthetic views and authority as separate facts

contexts = [{"view":"namespace-a", "canAdminister":True}, {"view":"namespace-b", "canAdminister":True}]
assert contexts[0]["view"] != contexts[1]["view"]
assert all(c["canAdminister"] is True for c in contexts)
assert not all(c["canAdminister"] is False for c in contexts)
print("different modeled views do not remove declared authority")

Expected output

different modeled views do not remove declared authority

The complete program evaluates two dictionaries and creates no namespace or capability. It makes no claim about an actual container’s privileges. The administration flag is explicitly fixture data rather than a kernel observation.

Treat syscall restriction as one part of the design

A syscall allowlist needs the actual program’s supported operations, architectures, libraries, and lifecycle behavior. A broad allowed syscall can operate on many objects, while argument pointers and application semantics require different controls. The second record is a fictional review inventory, not a BPF program or valid seccomp profile. It keeps architecture and runtime coverage unresolved. Upstream seccomp documentation explicitly distinguishes filtering from a complete sandbox. No filter is installed, and no blocked syscall is attempted. A list of syscall names cannot establish that the process cannot disclose data through an already permitted channel.

json A custom non-runnable sandbox review inventory

{"format":"classroom-sandbox-review","workload":"report-worker-lab","namespaceTypesReviewed":["mount","user"],"syscallPolicyProposed":true,"architecturesVerified":false,"libraryBehaviorVerified":false,"existingChannelsReviewed":false,"actualFilterInstalled":false}

The JSON is planning metadata and is not accepted seccomp, container, or kernel configuration. It starts no runtime and establishes no feature support. Proposed policy must remain distinct from verified effective restrictions.

Compose controls without multiplying unsupported guarantees

Combine least privilege, narrow filesystem access, supported syscall policy, mandatory controls, and application authorization according to the threat model. Interactions can weaken assumptions: a writable host mount or broad runtime grant may defeat the intended separation. A syscall filter does not repair a missing business authorization rule. Keep resource limits and availability questions distinct from confidentiality and integrity. A configuration’s marketing label is not evidence that these boundaries were reviewed. Explain the kernel/runtime trust and the exact protected outcome so another reviewer can challenge the design rather than trust the word sandbox.

Report the unexecuted kernel and runtime boundaries

An approved disposable verification should observe legitimate work, denied benign alternatives, and relevant escape-of-authority assumptions without testing real targets. Record exact runtime/kernel versions and supported features. This course runs only the dictionary model and displays a non-runnable record; it does not validate container security or a seccomp profile. If a feature is absent, keep that limitation visible rather than silently treating another control as equivalent. A precise conclusion says which view/authority distinction was modeled and which actual enforcement claims still need evidence.

Common errors and fixes

A separate hostname proves full isolation

Why it happens: One namespace view substitutes for authority analysis.
How to fix it: Review the relevant namespace types, grants, and shared resources.
Prevent it next time: State each boundary independently.

A syscall list is called a complete sandbox

Why it happens: Object authority and application semantics are omitted.
How to fix it: Combine supported controls and review permitted channels.
Prevent it next time: Keep filtering scope explicit.

An untested profile is marked enforced

Why it happens: Proposed metadata is confused with kernel execution.
How to fix it: Preserve pending feature and runtime checks.
Prevent it next time: Attach actual evidence to enforcement claims.

Check your understanding

1. Two contexts have different views but both canAdminister=true. What is established?

Show worked solution

The model demonstrates different views with unchanged declared authority. It does not evaluate any real namespace or host privilege. Review which actual resource and authority boundary the design intends to constrain before choosing mechanisms or claiming container containment.

2. Why can an allowed write-like operation still disclose information?