The 0.9.0 release notes mention "enhanced orchestrator-tool executor isolation via unidirectional seccomp." The implementation is good, but the default policy has a gap.
The orchestrator's seccomp now blocks `clone3` and `unshare`, preventing namespace escapes from the tool executor sandbox. However, the tool executor's own seccomp still permits `memfd_create` and `execve` on file descriptors. This allows a compromised tool to create an anonymous executable region and re-execute itself, potentially bypassing the `PR_SET_NO_NEW_PRIVS` pin if there's a kernel race.
Proposed patch to the default tool executor profile:
```c
// In security/seccomp/tool_executor.c
- SCMP_SYS(memfd_create),
- SCMP_SYS(execve),
+ // SCMP_SYS(memfd_create), // removed
+ // SCMP_SYS(execve), // removed
```
The orchestrator should handle all code execution via `execveat` with `AT_EMPTY_PATH` on a prepared fd, already filtered. The tool executor doesn't need these syscalls. Without this, the trust boundary is still porous under specific fault conditions.