- Sandbox-enabled native Action modules are never loaded into the privileged host Runtime.
- The worker enables
PR_SET_NO_NEW_PRIVSbefore Action code is loaded. - Landlock reduces filesystem rights monotonically.
- The Action directory is read/execute only by default.
- Writable temporary/state locations must be explicitly declared.
- Process spawning is denied by default.
- Memory and CPU have hard enforcement hooks.
- Mandatory controls fail closed when unsupported.
- A manifest requests rights; host policy remains authoritative.
- Terminal
.Okbelongs to the embedding Runtime and occurs only after its commit barrier.
allascode-admin
owns code/config and deploys
allascode-runtime
orchestrates with project read access
allascode-action
non-privileged worker identity
Prefer SSH keys and narrow sudo rules over direct password login.
Changing global file modes per execution introduces shared mutable security state and race windows. SandboxActor keeps host permissions stable and creates a per-process kernel security domain instead.
A native .so loaded into the Runtime shares its address space, so filesystem restrictions cannot protect Runtime heap, secrets, stacks, or libraries. The worker-process boundary is therefore mandatory when sandboxing native modules.
The manifest can request network allow-lists, but production enforcement must come from a configured network namespace/eBPF/cgroup network controller or equivalent. Unsupported requested enforcement must fail closed.
Seccomp is intended as a second syscall boundary generated from the Action execution class rather than one universal permissive profile.
Sandbox healers too. CodeHealer should receive write access only to the intended implementation.zig; SystemHealer only to the intended config path.