what are we defending against? A compromised exec plugin instance breaking out of its designated chroot jail and accessing host filesystem resources, leading to potential credential harvesting, lateral movement, or persistence mechanism installation.

I am conducting a pre-deployment assessment of the OpenClaw orchestration layer, specifically the dynamic plugin system. The exec plugin, which allows agents to perform sanctioned system operations, is configured to run within a chroot jail for isolation. However, during my adversarial simulation, I have observed consistent failure of the jail to constrain the plugin's process. The plugin's child processes appear to inherit the host's root filesystem view, not the chroot environment.

My attack tree for this vulnerability currently branches from the initial plugin execution:
* Primary Path: Plugin Process Execution
* Sub-node: Inadequate namespace isolation at process spawn
* Leaf: Possible missing `chdir()` to new root before `chroot()` call.
* Leaf: Potential privilege retention (CAP_SYS_CHROOT) allowing subsequent `chroot()` escape.
* Sub-node: Incorrect binding of required libraries and devices into the jail
* Leaf: /dev/null, /dev/zero, /dev/random not present, causing process to fall back to host devices.
* Leaf: Dynamic linker or essential shared libraries (e.g., libc) mounted at host paths, not jail paths.
* Secondary Path: Plugin Configuration & Launch
* Sub-node: Orchestrator service (claw-core) launching mechanism flaw
* Leaf: The `pivot_root` or `unshare` sequence is incorrect or omitted.
* Leaf: The user namespace is not created or is joined after the chroot operation.

The relevant section of my test orchestrator config is as follows:

```
plugins:
exec:
enabled: true
chroot_path: "/var/lib/openclaw/jails/exec_default"
drop_caps: ["CAP_SYS_CHROOT", "CAP_DAC_OVERRIDE"]
required_bind_mounts:
- "/lib/x86_64-linux-gnu"
- "/usr/lib/x86_64-linux-gnu"
- "/dev/log"
```

Despite this, a simple test command issued via the plugin, such as `ls /`, enumerates the host root directory, not the contents of `/var/lib/openclaw/jails/exec_default`. The control matrix is failing at the containment technical control.

My immediate hypotheses center on the order of operations in the plugin loader. Is the chroot being applied *after* the process forks and inherits the host's mount namespace? Furthermore, could this be an issue of the claw-core service itself running with elevated capabilities that are being inadvertently propagated? I am interested in the community's analysis of the capability gaps in our current isolation approach and any prior art within the Claw family for correctly sandboxing external binaries.