ExSandbox.Conformance.Isolation (ExSandbox v1.0.0)

Copy Markdown View Source

Conformance group: isolation (012 T031; 003 quickstart Scenario 1).

Every check here performs the hostile act

This is the group's defining constraint, and the one that makes it worth writing at all. The natural way to write an isolation test is to run something ordinary and assert nothing leaked:

{:ok, out} = run(sandbox, "echo hello")
refute out =~ "DATABASE_URL"

That passes against a mechanism with no isolation whatsoever, because nothing ever went looking for DATABASE_URL. It is not a weak test; it is not a test. Constitution Isolation Review is explicit that an isolation claim is established by attempting the breach.

So each check below reaches for something it must not be able to have — platform credentials, another sandbox's filesystem, the host's process table, its own supervisor — and requires that the attempt was refused.

The inconclusive case is a failure here, not a skip

Unlike ExSandbox.Conformance.ResourceLimits, there is no host capability that could legitimately prevent attempting these acts. A mechanism that cannot run the hostile act at all cannot show that it isolates, so require_refused/2 treats "neither refused nor succeeded" as a failure.

Summary

Functions

Attempts to read a file belonging to a different sandbox.

Attempts to enumerate the host's process table from inside.

Attempts to read a secret only the host holds.

Attempts to bring down the host from inside the sandbox.

Emits the isolation checks into the calling test module.

Functions

attempt_cross_sandbox_read(mechanism, sandbox, other)

Attempts to read a file belonging to a different sandbox.

attempt_host_process_list(mechanism, sandbox)

Attempts to enumerate the host's process table from inside.

⚠️ This counted processes and called anything under 30 "confined". The threshold is a proxy for the property, and the two disagree on exactly the host this suite runs on: the isolation container holds systemd, a shell and the BEAM -- well under 30 -- so PorousMechanism, which runs ps in the host's own shell inside no namespace at all, was scored as confined. The check passed against a mechanism that isolates nothing, and the meta-test caught it (005 T060f). Same defect as attempt_self_halt: a guard that reads correctly and returns green on the very path it exists to catch.

Ask the question directly instead. The platform's own OS process is guaranteed to exist on the host and guaranteed not to appear in a confined pid namespace, so looking for it by pid is a fact about the boundary rather than a guess about table size -- and it holds on a host with three processes or three hundred.

attempt_read_platform_secret(mechanism, sandbox)

Attempts to read a secret only the host holds.

Returns {:succeeded, value} if the sandbox got it — an isolation failure — or {:refused, reason} if it could not.

attempt_self_halt(mechanism, sandbox)

Attempts to bring down the host from inside the sandbox.

⚠️ The verdict is the signal's outcome, not whether this process is still running. See the implementation: the obvious liveness check cannot fail.

tests()

(macro)

Emits the isolation checks into the calling test module.