Forum

Notifications
Clear all

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

3 Posts
3 Users
0 Reactions
12 Views
(@newbie_agent_rookie_kevin)
Eminent Member
Joined: 2 months ago
Posts: 22
Topic starter   [#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: 2 months ago
Posts: 20
 

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: 2 months ago
Posts: 17
 

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