XiliuxA system has to run a chunk of code you don't control —a plugin, a dependency, something generated— and you want to guarantee that code cannot touch the file system or spawn processes. Not that it "shouldn't": that it can't, mechanically. That's capability confinement, and it's one of the central problems of runtime security.
Designing it and demonstrating it are two different things, and confusing them is expensive.
A design is a claim
You can write an impeccable document: "access to fs and to spawning processes is controlled like this, with these mechanisms, under this threat model". It's real and necessary work. But it's a claim. And the failure mode of a security boundary is that it looks like it holds until it doesn't —silent, invisible in tests, visible only when someone crosses it—.
In security, an unverified claim has exactly the shape of a beautiful, wrong architecture. The design can assume that a module-loader hook fires at a point where it actually doesn't, and all the reasoning hanging off that is correct and worth nothing.
The mechanisms exist, and there are several
In Node, to name a concrete runtime, there are at least three layers, and they aren't interchangeable:
- The native permission model (
--permission,--allow-fs-read…), which cuts access tofsand to spawning processes at the whole-process level. - SES / Hardened JavaScript (Compartments,
lockdown()), which confines what each module can import within the process. - Module-loader interception, which controls what resolves when the code asks for something.
Choosing well among them is the design. But choosing well doesn't prove the choice holds against the real dependency tree you're going to run.
Demonstrate instead of claim
The alternative to signing off a design is delivering a confinement harness: untrusted code that tries to reach the dangerous capability —open a file, spawn a process— against the real runtime and its real dependency tree, and a log that shows each attempt was blocked. Or, if something escapes, exactly where.
The difference isn't cosmetic. "I think it's confined" and "here's the evidence that an attempt to read a system file from the plugin returned permission denied" are claims of very different weight. The second is the discipline I use for everything else applied to security: cross the program boundary and measure what comes out, not what you think comes out.
The honest part
There's a temptation to sign off the boundary from an authority you haven't earned —because the design looks good, because the mechanisms exist—. The honest discipline is the opposite: what you can back today, you back; what depends on a runtime detail you don't master, you don't assert from memory: you validate empirically, and what can't be demonstrated yet is marked as the seam to co-review, not hidden.
A demonstrated boundary covers exactly the gap a claimed one leaves open. And for whoever has to trust the confinement, a harness that attacks its own boundary and keeps the evidence is worth more than the word of whoever designed it.