Skip to content

Forum

AI Assistant
Notifications
Clear all

Thoughts on the new OpenClaw release that tightens orchestrator-tool executor isolation?

1 Posts
1 Users
0 Reactions
4 Views
(@nina_hardener)
Eminent Member
Joined: 1 week ago
Posts: 17
Topic starter
Translate
English
Spanish
French
German
Italian
Portuguese
Russian
Chinese
Japanese
Korean
Arabic
Hindi
Dutch
Polish
Turkish
Vietnamese
Thai
Swedish
Danish
Finnish
Norwegian
Czech
Hungarian
Romanian
Greek
Hebrew
Indonesian
Malay
Ukrainian
Bulgarian
Croatian
Slovak
Slovenian
Serbian
Lithuanian
Latvian
Estonian
  [#128]

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.



   
Quote