OS-level confinement for the BEAM mechanism on macOS (014 T011 – T015, from 005 R9b and 014's re-measurement at docs/legacy/specify/014-desktop-deployment/spikes/darwin-hardening/baseline.md).

The composition, and why it has this exact shape

sandbox-exec -f <profile>                       # filesystem + network
  /bin/sh -c 'ulimit -t <N>; exec …'            # RLIMIT_CPU
    taskpolicy -m <M>                           # memory
      <target> <args…>

Measured on macOS 26.5 (25F71), the same build 005 R9b was measured on: hog 300 under -m 150 exits 137, a spinner that does not limit itself exits 152 under ulimit -t 2, an ordinary crash exits 139, and a program inside its caps exits 0. Four outcomes, mutually distinguishable (SC-002, FR-016).

⚠️ taskpolicy must be the IMMEDIATE PARENT of the target. R9b measured taskpolicy -m 100 sandbox-exec … ./hog 300 allocating 300 MB under a nominal 100 MB cap and exiting 0 — the cap silently lost across the intervening exec, failing open. Reproduced here while writing this module: inverted, the hog prints allocated 300 MB OK.

The rule that generalises from that trap is taskpolicy immediately above the target, not "no shell anywhere" (baseline Finding 3). A shell placed before taskpolicy that execs keeps the memory cap, because exec replaces the shell image rather than forking. That is the only reason the CPU cap is reachable at all: RLIMIT_CPU needs something to call ulimit, and this is where it can stand without breaking the memory cap.

⚠️ The intervening shell is an injection surface, and it is closed by argv

ExSandbox.Hardening.Linux composes argv directly and never reaches a shell. This composition does, and /bin/sh -c takes a single string a shell parses — so a target path or argument interpolated into that string is command injection through the sandbox's own command line, which no sandbox-exec profile closes.

Nothing tenant-influenced is ever interpolated. The script is a constant plus two integers this module formats itself; the target and every argument are passed after the script, where sh binds them to $0 and $@:

/bin/sh -c 'ulimit -t 2; exec /usr/sbin/taskpolicy -m 150 "$0" "$@"' \
  /path/to/target arg1 arg2

They are therefore argv positions, not text, and never reach the parser. ExSandbox.Hardening.DarwinTest proves it by launching a target whose arguments carry ;, $(…), backticks, |, & and > with side effects aimed at a directory the profile permits writing, and asserting the bytes arrive literally and no side effect occurs.

Why the profile starts from (allow default) — and what that costs

(deny default) is not viable and this is measured, not assumed: it kills even /bin/echo, because dyld cannot start. R9b recorded it; the template this module renders (docs/legacy/specify/005-sandbox-beam/spikes/macos-isolation/work.sb) carries the finding in its own first comment.

So the profile is a deny-list over a permissive default, which is weaker than default-deny confinement: any operation nobody thought to deny is allowed. That gap is the reason FR-013 exists — to report the isolation level honestly — and :privilege_separation stays unavailable on Darwin for exactly this reason (T021). It must not be papered over by describing this profile as confinement equivalent to bwrap's.

Note that ExSandbox.Hardening.Confinement reaches a stronger, near default-deny profile for a control-plane process, by enumerating the runtime's read set. That is a different problem: it confines one known binary to one known path. Here the target is arbitrary tenant code whose read set is unknown before it runs, and an incomplete permit list does not confine it — it kills it before its first instruction, which reads as every breach assertion passing (R30's measured 134 on every case, control included).

⚠️ RLIMIT_AS, RLIMIT_DATA and RLIMIT_RSS do not work on Darwin

Measured on this host (T001, and R9b before it): setrlimit on all three fails with EINVAL, from a soft and hard limit of RLIM_INFINITY. RLIMIT_CPU is the one that sets.

This matters to anyone porting the Linux mechanism: the address-space cap that would be the obvious memory limit is unavailable, which is why the memory cap here is taskpolicy -m and not a setrlimit call. A port that reached for RLIMIT_AS would cap nothing, silently, and every check short of breaching it would report success.

⚠️ ulimit -t is per-process and inherited, not pooled

Each child gets its own fresh budget, so a target that forks multiplies the CPU it can consume. This is strictly weaker than a cgroup CPU quota, and it is a gap FR-013a must report rather than paper over. It is not a reason to omit the cap (FR-014): a per-process ceiling stops the single runaway loop, which is the case US2 names.

Refusal, never a spec with the cap missing

Every function that cannot build a requested cap returns {:error, {:cannot_enforce, capability, detail}}. It never returns a launch spec with the cap omitted — that is the fail-open shape ExSandbox.Hardening's docstring forbids, and it is indistinguishable from success at every layer that does not breach the cap to check.

What is refused here, and why:

• :disk_mb — always. Darwin has no per-process disk quota this composition can impose. A spec that quietly dropped it would report a disk cap that does not exist.
• :memory_mb when taskpolicy is absent from the host.
• :cpu_millicores without a :wall_clock_seconds budget — see apply/3 for why the two are one number here.
• any launch at all without a positive :wall_clock_seconds — see below.

What this module does NOT enforce, and refuses to launch without

The wall-clock budget. launch_spec/0 describes how to start a process; nothing in it can kill one later. The caller enforcing :wall_clock_seconds by killing the OS pid is the supervisor's job, and 014 T009 verifies the outcome is distinguishable from every exit status — there is none.

⚠️ Not enforcing it is not a licence to launch without one (FR-014b, SC-006c, T019). An idle process consumes no CPU, so ulimit -t never fires; it allocates nothing, so taskpolicy -m never fires; it does not crash. No layer of this composition ends it. So apply/3 returns {:error, {:cannot_enforce, :time_budget, …}} rather than a spec with no budget behind it: this is the last point at which the run can be refused instead of started, and a run with no terminating condition is the one shortfall FR-014b says must refuse rather than degrade.