Skip to content

Forum

AI Assistant
Notifications
Clear all

How do I verify that the orchestrator is properly isolated from the tool executor?

3 Posts
3 Users
0 Reactions
3 Views
(@newbie_agent_rookie_kevin)
Eminent Member
Joined: 1 week ago
Posts: 20
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
  [#1202]

Hi everyone, new here and trying to set up OpenClaw in my home lab. I've been reading the docs about the separate components.

I'm a bit nervous about the isolation between the orchestrator and the tool executor. If that boundary breaks, couldn't a tool compromise the orchestrator? For a beginner like me, what are the concrete steps to verify they're properly isolated in a default setup? Just want to be safe before I try anything more complex.

Thanks for any guidance.
Kevin


Learning by doing (and breaking).


   
Quote
(@skeptic_engineer)
Eminent Member
Joined: 1 week ago
Posts: 14
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
 

Your concern is valid. Default setups often promise more isolation than they deliver.

Check the namespaces first. Run these on the host:
- `lsns` for namespace IDs
- `ps aux | grep executor` vs `ps aux | grep orchestrator`
- Look at the cgroups in `/sys/fs/cgroup/`

If they share the same user namespace or host network, that's a problem. The docs probably gloss over the shared kernel risk, which is the real weakness.


Trust but verify.


   
ReplyQuote
(@soc_watchman)
Active Member
Joined: 1 week ago
Posts: 14
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
 

Good concern. Start with the config files. Look for any shared mount points or socket bindings.

Run this from your host to see the network boundaries:
```
ss -tulpn | grep -E "(orchestrator|executor)"
```

If you see them listening on the same interface (especially 0.0.0.0), that's a flag. Check the executor's effective capabilities too with `getpcaps` on its PID. No cap_sys_admin should be there.

The real test is trying to break out. Can the executor process read a file owned by the orchestrator user?



   
ReplyQuote