Audit Authority as a Data Flow

Capability-oriented design becomes useful when authority is treated as a visible data flow. A process should not gain access only because it knows a global name or because the runtime happens to expose a large ambient namespace. The design question is direct: which handles enter the process, what operations does each handle permit, and where can those rights travel next?

Start with an authority inventory

List every resource that the workload can affect. Include files, directories, sockets, clocks, random sources, process controls, logging channels, and devices. For each resource, record the concrete handle or interface that makes access possible. Do not write “filesystem access” when the process receives one directory descriptor with a limited purpose. Do not write “network access” when only one connected socket is supplied.

A useful inventory has these fields:

1. resource and owning subsystem;
2. initial authority source;
3. operations permitted by the handle;
4. whether new authority can be derived;
5. whether the handle can be transferred;
6. lifetime and revocation behavior; and
7. evidence that the restriction is enforced.

The former CloudABI work explored secure and testable software for UNIX-like systems. Its historical source repository remains available in the NuxiNL CloudABI repository. That repository is useful historical evidence, but it is not a current platform guarantee. This publication is not the original CloudABI project and does not publish compatibility claims for its code.

Draw transfers, not only components

A component diagram can show where services run while hiding how authority moves. Add an edge for every handle transfer. Name the operation that creates the edge. If a supervisor opens a directory and passes it to a worker, show the directory handle, the permitted operations, and whether the worker can pass it again.

Pay attention to authority amplification. A read-only configuration handle can still contain a token that grants broader access. A logging channel can disclose secrets. A directory handle can expose more names than intended. A network service can perform privileged operations on behalf of a caller. Capability boundaries must include the meaning of data, not only kernel object types.

Test negative cases

A positive test proves that an allowed operation works. It does not prove that other operations fail. For every boundary, build a negative test matrix. Try names outside the supplied directory, address families outside the contract, operations after handle closure, invalid transfer attempts, and calls made before initialization.

Record the exact failure class. A permission error, missing name, closed descriptor, and unsupported operation are different observations. An unexpected success is a design defect. An unexpected crash is also evidence because it can show that the application assumed ambient access during startup.

Keep the model tied to deployment

The authority map must match the launched binary and its real supervisor configuration. Build scripts, test harnesses, and production launchers often supply different resources. Store the runtime configuration beside the test result. Repeat the audit after a dependency, platform, or initialization path changes.

The final output is not a claim that the process is secure. It is a bounded statement: these handles were supplied, these operations were tested, and these transfers were observed under this build and platform. That statement is narrow enough to verify and useful enough to improve.