Worker Executor and Lower-privilege Sandbox

1. The problem: why supervisor-authority job execution is unsafe

The supervisor is a long-lived lifecycle process; a job payload is short-lived and variable. If the job inherits the same service identity, privileges, filesystem reach, and network authority, the trust boundary disappears. This lesson separates execution identity and effective authority from supervisor authority rather than merely starting a differently named child process.

Base rule: requested authority, allowed authority, and effective authority are distinct. PASS requires evidence that the executor did not exceed the allowed profile.

2. Owned boundary and non-goals

LOC-007 owns only the executor/sandbox boundary. Restart/watchdog policy belongs to LOC-006; coordinator envelope/version negotiation belongs to LOC-008. A sandbox also does not prove arbitrary code is benign; it narrows reachable authority.

Every conclusion must trace to this boundary: executor identity, requested/allowed/effective policy, and bounded result evidence.

3. Minimal job contract

A Job Contract should be a narrow request: job type, bounded input/output, timeout, resource limits, requested capabilities, and an effect profile. It must not implicitly transfer supervisor credentials or privileges.

Record requested_capabilities explicitly so admission can compare them with allowed_capabilities before launch.

4. Supervisor identity versus executor identity

The executor should run under an identity whose authority is narrower than the supervisor. A different username is not enough; privilege drop and effective token/context matter. If the executor reuses supervisor identity and authority, the identity evidence is unacceptable.

Windows restricted tokens and Linux/systemd hardening are useful mechanisms, but the effective context still needs evidence.

5. Capability admission: requested must fit allowed

Before execution, requested capabilities must fit the allowed profile. An out-of-profile request must not be repaired by silently widening the sandbox.

For example, a converter may need read_input and write_output, but a request for read_credentials or arbitrary child processes is a typed non-success case.

6. Filesystem policy: read-only base, writable workspace

Model exact paths: application/base files read-only, a bounded workspace writable, credential stores inaccessible, and temporary files isolated. A different working directory is not isolation.

Failure probe: a requested path outside the allowed workspace is rejected before execution.

7. Process and device boundary

Make child-process policy explicit: deny, allowlist, or a bounded helper. Device access is also explicit; a job that does not need GPU, USB, or serial access should not inherit them by default.

General process-spawn authority is a mismatch when the job does not require it.

8. Network scope as an effect profile

Network is a separate capability. A job with no network need can use none; the transfer case adds exactly one approved endpoint. Changing the network rule must not weaken filesystem, process, or secret restrictions.

Requested network settings are not proof of the effective boundary; record effective evidence.

9. Resource envelope and timeout

CPU, memory, and wall timeout bound operational impact. Resource limits are not a complete security boundary, but they reduce blast radius.

The result must distinguish completed, timeout, resource-limit termination, and executor failure.

10. Secret exposure and environment allowlist

Environment inheritance is a common authority leak. Use an allowlist rather than copying the supervisor environment. Tokens, credentials, and secret-store paths remain excluded unless an explicit authorized job contract requires otherwise.

Failure probe: a supervisor-only secret in the executor environment blocks PASS even when resource limits are correct.

11. Linux/systemd: requested setting is not effective sandbox proof

systemd controls such as NoNewPrivileges=, ProtectSystem=, and PrivateTmp= can harden execution, but some mechanisms depend on kernel, namespace, and capability support. Treat configuration as requested state, not proof of effective isolation.

If a required primitive is unavailable, preserve ISOLATION_UNAVAILABLE/DEFER until effective evidence exists.

12. Windows restricted token: a primitive, not the entire sandbox

A Windows restricted token can remove privileges, apply deny-only SID behavior, and add restricting SIDs. That is useful, but it does not by itself define filesystem, network, process-spawn, or resource policy.

Keep token evidence as one matrix dimension rather than equating it with a complete sandbox.

13. Result envelope and audit evidence

An executor result should contain more than an exit code: sandbox profile/version, effective capabilities, termination reason, result status, and an audit reference. Requested/effective mismatch is recorded explicitly.

This makes retry, incident review, and recovery evidence-driven rather than based on “the process ran.”

14. Lab: Worker Executor Privilege & Sandbox Matrix v1

The lab contains eight synthetic fixtures and a learner starter with no final labels. Compute identity, capability, isolation, filesystem, network/process, secret state, decision, and reason separately.

Negative cases include path escape, unavailable isolation, secret exposure, capability widening, effective-authority widening, and supervisor-identity reuse. No real operating-system privilege is modified.

15. Transfer and exit criterion

Transfer: a new job needs outbound access only to api.example.test:443. Add that narrow network allowance while preserving credential-store denial, arbitrary-child denial, the same workspace boundary, and lower-privilege executor identity.

Exit criterion: build Worker Executor Privilege & Sandbox Matrix v1 from evidence and explain why requested configuration alone is not proof of effective authority.