Section 50: Runtime Isolation and Sandboxing¶

TECHSPEC-50 — Section 50 · Version 0.1 · Status: Initial Draft

Status: draft. This section is an Initial Draft (Section 57 is a Working Register). It describes intended or proposed behavior, not a finalized, implemented language rule. Do not treat examples here as normative.

1. Purpose¶

Runtime isolation limits the damage that a defective or untrusted program can cause.

Isolation is a defense-in-depth measure. It does not prove that a program is correct or that the host system is secure.

2. Isolation Boundaries¶

The runtime should support configurable restrictions on: - Filesystem access. - Network access. - Process creation. - Environment access. - Database connections. - Device access. - Memory and CPU resources. - Inter-process communication.

3. Capability-Based Access¶

A program receives only the capabilities required for its declared work.

Rules: - Capabilities must be granted explicitly. - A module cannot silently expand its own permissions. - Child tasks receive only authorized capabilities. - Capability delegation must be explicit and scoped. - Revocation behavior must be defined.

4. Filesystem Isolation¶

Where supported, the runtime should restrict file access to declared roots or specific handles.

Path validation alone is insufficient against all symlink and race conditions. The implementation should use operating-system mechanisms that bind access to authorized filesystem objects where available.

5. Network Isolation¶

Network access must be controlled by destination, protocol, and operation where practical.

The runtime must distinguish permission to connect from successful communication and from trust in the remote endpoint.

6. Process Isolation¶

Untrusted code should run with restricted operating-system privileges and controlled environment inheritance.

The runtime must not treat a language-level permission declaration as a substitute for operating-system enforcement.

7. Isolation Profiles¶

Possible profiles include: - Restricted: no external access unless explicitly granted. - Application: declared application capabilities only. - Administrative: elevated capabilities requiring explicit authorization.

Profile names are provisional. The final model must define exact enforcement behavior.

8. Failure and Escape Reporting¶

The runtime should report denied operations, resource-limit violations, and isolation failures.

A sandbox escape or failure of the underlying enforcement mechanism is a security incident, not an ordinary permission denial.

9. Platform Limitations¶

Isolation strength depends on the operating system, runtime, deployment configuration, and available security primitives.

The compiler must not claim equivalent isolation on every platform without evidence.

10. Verification¶

Reports distinguish declared restrictions, runtime-enforced restrictions, platform assumptions, and independently tested isolation properties.

11. Design Goal¶

Untrusted code must begin with minimal authority. The runtime should enforce restrictions independently of the code's own claims.

Source and related sections¶

Source file: TECHSPEC-50.md (preserved in source-original/LANG/). See the specification index, the glossary, and the cross-reference index.