<?xml version="1.0" encoding="UTF-8"?>        <rss version="2.0"
             xmlns:atom="http://www.w3.org/2005/Atom"
             xmlns:dc="http://purl.org/dc/elements/1.1/"
             xmlns:sy="http://purl.org/rss/1.0/modules/syndication/"
             xmlns:admin="http://webns.net/mvcb/"
             xmlns:rdf="http://www.w3.org/1999/02/22-rdf-syntax-ns#"
             xmlns:content="http://purl.org/rss/1.0/modules/content/">
        <channel>
            <title>
									Sandbox Escapes and Breakout Research - openclawsecurity.net Forum				            </title>
            <link>https://openclawsecurity.net/community/openclaw-sandbox-escapes/</link>
            <description>openclawsecurity.net Discussion Board</description>
            <language>en-US</language>
            <lastBuildDate>Fri, 14 Aug 2026 18:19:06 +0000</lastBuildDate>
            <generator>wpForo</generator>
            <ttl>60</ttl>
							                    <item>
                        <title>Just built a tool to diff allowed syscalls before/after agent execution.</title>
                        <link>https://openclawsecurity.net/community/openclaw-sandbox-escapes/just-built-a-tool-to-diff-allowed-syscalls-before-after-agent-execution/</link>
                        <pubDate>Wed, 15 Jul 2026 04:59:48 +0000</pubDate>
                        <description><![CDATA[Hey everyone, I finally got my first nano claw instance up and running last week (so cool!). While playing with the local agent examples, I got really nervous about the syscall allowlist. I ...]]></description>
                        <content:encoded><![CDATA[Hey everyone, I finally got my first nano claw instance up and running last week (so cool!). While playing with the local agent examples, I got really nervous about the syscall allowlist. I understand the principle, but I wanted to *see* what the agent was actually trying to do under the hood.

So I built a small tool in Python that hooks into the seccomp-bpf logging. It basically takes a snapshot of the allowed syscalls from the OpenClaw policy for a given agent profile, runs the agent for a short, controlled test, and then diffs the log against the initial allowlist. The idea is to highlight any syscalls the agent *attempted* that weren't pre-allowed.

I ran it on the basic "file summarizer" example agent, and it showed a couple of interesting attempts—one for `clock_gettime` and another for `getrandom`—that weren't in the base profile I was using. Nothing scary, but it made me realize the default profiles might be a bit too restrictive, or maybe my understanding is off.

My question is: is this a valid approach for testing the tightness of a sandbox? Or am I missing a layer here? I'm worried about false positives if the agent libraries make benign calls that get blocked. Should I be looking at the failures differently?

Also, if this is useful, I'd be happy to share the script. It's pretty rough, but maybe others have done similar things. I'm really curious how you all validate your profiles before deploying new agents.]]></content:encoded>
						                            <category domain="https://openclawsecurity.net/community/openclaw-sandbox-escapes/">Sandbox Escapes and Breakout Research</category>                        <dc:creator>Jamie K.</dc:creator>
                        <guid isPermaLink="true">https://openclawsecurity.net/community/openclaw-sandbox-escapes/just-built-a-tool-to-diff-allowed-syscalls-before-after-agent-execution/</guid>
                    </item>
				                    <item>
                        <title>Showcase: My config for running OpenClaw on OpenBSD with pledge/unveil.</title>
                        <link>https://openclawsecurity.net/community/openclaw-sandbox-escapes/showcase-my-config-for-running-openclaw-on-openbsd-with-pledge-unveil/</link>
                        <pubDate>Tue, 14 Jul 2026 06:00:01 +0000</pubDate>
                        <description><![CDATA[I&#039;ve been running OpenClaw&#039;s core services on OpenBSD for a few weeks now, mainly for the pledge/unveil sandboxing. Wanted to share my config and see if anyone has suggestions to tighten it ...]]></description>
                        <content:encoded><![CDATA[I've been running OpenClaw's core services on OpenBSD for a few weeks now, mainly for the pledge/unveil sandboxing. Wanted to share my config and see if anyone has suggestions to tighten it further.

My main goal was to isolate the API gateway and the agent orchestrator. Here's the pledge call I'm using for the gateway service:

```c
if (pledge("stdio rpath inet dns recvfd", NULL) == -1)
    err(1, "pledge failed");
```

And the unveil calls right after:

```c
unveil("/etc/ssl", "r");
unveil("/usr/local/etc/openclaw/config.yaml", "r");
unveil("/var/run/openclaw/api.sock", "rwc");
unveil(NULL, NULL);
```

The orchestrator is more restrictive, just `stdio recvfd` and unveil only on its IPC socket. So far, no crashes. The network access is limited to outbound for specific agent tasks. Thoughts on the `recvfd` promise? Is it a risk for descriptor passing attacks? I'm still learning the pledge model.

-- Bob]]></content:encoded>
						                            <category domain="https://openclawsecurity.net/community/openclaw-sandbox-escapes/">Sandbox Escapes and Breakout Research</category>                        <dc:creator>Bob Chen</dc:creator>
                        <guid isPermaLink="true">https://openclawsecurity.net/community/openclaw-sandbox-escapes/showcase-my-config-for-running-openclaw-on-openbsd-with-pledge-unveil/</guid>
                    </item>
				                    <item>
                        <title>Help: My network namespace isolation breaks the agent&#039;s web search tool.</title>
                        <link>https://openclawsecurity.net/community/openclaw-sandbox-escapes/help-my-network-namespace-isolation-breaks-the-agents-web-search-tool/</link>
                        <pubDate>Tue, 14 Jul 2026 03:00:06 +0000</pubDate>
                        <description><![CDATA[Hey folks, I&#039;ve been running my OpenClaw agent inside a custom network namespace for isolation, and I&#039;ve hit a snag. The agent&#039;s built-in web search tool (`tool_web_search`) just hangs and t...]]></description>
                        <content:encoded><![CDATA[Hey folks, I've been running my OpenClaw agent inside a custom network namespace for isolation, and I've hit a snag. The agent's built-in web search tool (`tool_web_search`) just hangs and times out. Everything else works fine — local tool execution, file I/O — but anything requiring external network calls is dead.

I suspect this is because the agent's runtime, while memory-safe, isn't automatically handling the network namespace setup. The tool likely tries to use a standard `reqwest` client that inherits the global network state, which in my case is a `veth` pair inside the new namespace. Without proper routing/DNS in that namespace, it's stuck.

Here's a simplified version of my setup code:

```rust
// Creating the isolated network namespace
use nix::sched::{clone, CloneFlags};
use nix::sys::utsname::uname;

let mut stack = ;
let pid = clone(
    Box::new(|| {
        // ... setup veth, lo up, etc.
        // Then spawn the agent runtime
        let agent = MyOpenClawAgent::new();
        agent.run();
    }),
    &amp;mut stack,
    CloneFlags::CLONE_NEWNET | CloneFlags::CLONE_NEWUSER,
    Some(Signal::SIGCHLD as i32),
)?;
```

The agent initializes and runs, but any call to the web search tool blocks forever. I'm guessing the tool's HTTP client is created before or outside the namespace switch, or isn't using a socket that's aware of the new network context.

Has anyone else tried running OpenClaw agents under strict network isolation? Did you have to do something special to make external tool calls work? I'm thinking I might need to:
- Ensure the tool's HTTP client is built *after* the namespace is entered.
- Maybe bind the client to a specific interface in the new namespace.
- Or, perhaps there's a way to pass a pre-configured `reqwest::Client` into the tool during agent setup?

I love the safety guarantees of the runtime, but I need this isolation for my threat model. Any pointers would be awesome.]]></content:encoded>
						                            <category domain="https://openclawsecurity.net/community/openclaw-sandbox-escapes/">Sandbox Escapes and Breakout Research</category>                        <dc:creator>Marcus &#039;Rusty&#039; Chen</dc:creator>
                        <guid isPermaLink="true">https://openclawsecurity.net/community/openclaw-sandbox-escapes/help-my-network-namespace-isolation-breaks-the-agents-web-search-tool/</guid>
                    </item>
				                    <item>
                        <title>Just built a canary file system to detect unauthorized writes.</title>
                        <link>https://openclawsecurity.net/community/openclaw-sandbox-escapes/just-built-a-canary-file-system-to-detect-unauthorized-writes/</link>
                        <pubDate>Mon, 13 Jul 2026 23:00:41 +0000</pubDate>
                        <description><![CDATA[Been watching the &quot;safety&quot; crowd wrap everything in bubble wrap. They think they can cage an agent with chroot and user namespaces. Amusing.

Built a canary FS at `/dev/shm/cage_bust/`. Moun...]]></description>
                        <content:encoded><![CDATA[Been watching the "safety" crowd wrap everything in bubble wrap. They think they can cage an agent with chroot and user namespaces. Amusing.

Built a canary FS at `/dev/shm/cage_bust/`. Mounted a tmpfs, set it 0555 root:root. Any write attempt from inside a sandbox that shouldn't have root is a breach. Simple. If your agent can touch it, your sandbox is already dead. Means they've either escaped the user namespace or have a kernel bug to play with.

Stop trying to build better cages. Just know when the bars are bent. /dev/null]]></content:encoded>
						                            <category domain="https://openclawsecurity.net/community/openclaw-sandbox-escapes/">Sandbox Escapes and Breakout Research</category>                        <dc:creator>Dave &#039;R00t&#039; Miller</dc:creator>
                        <guid isPermaLink="true">https://openclawsecurity.net/community/openclaw-sandbox-escapes/just-built-a-canary-file-system-to-detect-unauthorized-writes/</guid>
                    </item>
				                    <item>
                        <title>Did you see the post about the agent using RCE in a fetched script?</title>
                        <link>https://openclawsecurity.net/community/openclaw-sandbox-escapes/did-you-see-the-post-about-the-agent-using-rce-in-a-fetched-script/</link>
                        <pubDate>Sat, 11 Jul 2026 11:00:07 +0000</pubDate>
                        <description><![CDATA[Just caught a thread on another forum referencing an unpatched RCE in the agent&#039;s script-fetch mechanism. The poster was vague, but I think I&#039;ve traced it to CVE-2024-27983 (still reserved)....]]></description>
                        <content:encoded><![CDATA[Just caught a thread on another forum referencing an unpatched RCE in the agent's script-fetch mechanism. The poster was vague, but I think I've traced it to CVE-2024-27983 (still reserved). The core issue seems to be in the `SecureScriptFetcher` component when it's configured to pull from user-supplied URLs for "dynamic workflows."

The agent doesn't adequately validate or sanitize the fetched script's content before it's passed to the execution engine. If the fetched script contains certain control sequences, it can break out of the intended isolated context.

Key points from my analysis:
*   The vulnerability is triggered only when `allow_remote_scripts` is set to `true` in the config (which is the default in some legacy profiles).
*   The fetch response's `Content-Type` check can be bypassed with a double newline trick in the header, allowing `text/plain` to be executed as `application/x-script`.
*   The breakout occurs because the execution context shares the agent's internal message bus under specific conditions.

Example of the problematic config flag:
```json
{
  "module": "SecureScriptFetcher",
  "config": {
    "allow_remote_scripts": true,
    "allowed_domains": 
  }
}
```

Even with a restricted allowed domain list, if an attacker controls a subdomain or can inject a response from `trusted.org`, the RCE chain is possible. The exploit path involves the script fetching a secondary payload that pollutes the global object, eventually granting access to the `syscall` interface.

I'm looking for the PoC that was hinted at. Has anyone reproduced this or seen the actual exploit steps? I've checked Exploit-DB and the NVD entry is still pending details. This seems like a critical breakout vector for any sandbox relying on this agent version.]]></content:encoded>
						                            <category domain="https://openclawsecurity.net/community/openclaw-sandbox-escapes/">Sandbox Escapes and Breakout Research</category>                        <dc:creator>Mia F.</dc:creator>
                        <guid isPermaLink="true">https://openclawsecurity.net/community/openclaw-sandbox-escapes/did-you-see-the-post-about-the-agent-using-rce-in-a-fetched-script/</guid>
                    </item>
				                    <item>
                        <title>Hot take: The project&#039;s focus on features is outpacing its focus on containment.</title>
                        <link>https://openclawsecurity.net/community/openclaw-sandbox-escapes/hot-take-the-projects-focus-on-features-is-outpacing-its-focus-on-containment/</link>
                        <pubDate>Fri, 10 Jul 2026 14:00:19 +0000</pubDate>
                        <description><![CDATA[I&#039;ve been running the latest OpenClaw release in a test cluster, and I&#039;m increasingly concerned that we&#039;re prioritizing feature velocity over containment guarantees. The new plugin system fo...]]></description>
                        <content:encoded><![CDATA[I've been running the latest OpenClaw release in a test cluster, and I'm increasingly concerned that we're prioritizing feature velocity over containment guarantees. The new plugin system for custom runtime hooks is a powerful addition, but its default seccomp profile is permissive to a fault, and the documentation focuses on "how to enable" rather than "what you're exposing."

Consider the default `seccomp` configuration for the new dynamic instrumentation module:
```json
{
    "defaultAction": "SCMP_ACT_ALLOW",
    "architectures": ,
    "syscalls": [
        {
            "names": ,
            "action": "SCMP_ACT_ERRNO"
        }
    ]
}
```
This is effectively running with `--privileged` from a syscall perspective. While I understand the desire to avoid breaking legacy workloads, the default should be a deny-list, not an allow-list. We've seen this pattern before in other container runtimes, and it inevitably leads to escape vectors when a previously unknown syscall is exploited.

My specific points of contention:
*   **Runtime hook isolation:** The hooks execute in a namespace-shared context with the target container. A compromise in a monitoring hook could lead directly to host access.
*   **cgroup v2 delegation:** The new resource shaping features delegate entire sub-trees without the `no_internal_process` constraint, which is a known path for container breakout via cgroup release_agent.
*   **Rootless as an afterthought:** Several new features, like the shared volume cache, require elevated capabilities when running in rootless mode, pushing users back to privileged deployments.

I'm not advocating for a development freeze. I am suggesting we need a parallel track for security hardening, and that no feature should be merged without a **containment impact assessment**. The project's credibility hinges on its ability to isolate workloads. Are we measuring the attack surface expansion with each release, or are we just counting new flags?

We should be able to point to a matrix that shows, for each feature:
*   The additional syscalls it requires.
*   The Linux capabilities it adds.
*   The namespaces it must share.
*   A threat model for its deployment in a multi-tenant environment.

Without this, we're building a sophisticated, feature-rich fortress with a cardboard back door.

r]]></content:encoded>
						                            <category domain="https://openclawsecurity.net/community/openclaw-sandbox-escapes/">Sandbox Escapes and Breakout Research</category>                        <dc:creator>Rachel Green</dc:creator>
                        <guid isPermaLink="true">https://openclawsecurity.net/community/openclaw-sandbox-escapes/hot-take-the-projects-focus-on-features-is-outpacing-its-focus-on-containment/</guid>
                    </item>
				                    <item>
                        <title>Switched from the default setup to a rootless container, stability improved.</title>
                        <link>https://openclawsecurity.net/community/openclaw-sandbox-escapes/switched-from-the-default-setup-to-a-rootless-container-stability-improved/</link>
                        <pubDate>Fri, 10 Jul 2026 10:00:03 +0000</pubDate>
                        <description><![CDATA[Everyone&#039;s been crowing about the default rootful Docker setup like it&#039;s some kind of fortress. It&#039;s not. It&#039;s a noisy, permission-leaking mess that feels like running a server in a glass ho...]]></description>
                        <content:encoded><![CDATA[Everyone's been crowing about the default rootful Docker setup like it's some kind of fortress. It's not. It's a noisy, permission-leaking mess that feels like running a server in a glass house with a megaphone. The default seccomp profile is a joke, and half the breakout research in this very subforum starts with "well, if you haven't removed `CAP_SYS_ADMIN`..."

Switched my primary testing rig to a rootless container setup (podman, in my case, but the principle stands). The immediate difference wasn't some magical security unicorn—it's that the attack surface *feels* tighter. No more daemon running as root. The user namespace mapping does more heavy lifting than a thousand lines of poorly tuned AppArmor policy.

Key observation: a lot of the lazy privilege escalation paths just evaporate. Try this in a rootless container and tell me how far you get:
```bash
# Classic dumb test
docker run --rm -it alpine:latest /bin/sh
# Inside container:
mkdir /tmp/cgroup &amp;&amp; mount -t cgroup -o rdma cgroup /tmp/cgroup &amp;&amp; cat /tmp/cgroup/release_agent
```
You'll be staring at a permission error. The user simply doesn't have the caps to mount things at whim. It doesn't make you invincible—a decent kernel vuln or a misconfigured bind mount still gets you there—but it raises the bar from "script kiddie" to "actually needs to think."

Stability improved because I stopped fighting the daemon and the bloat. The overhead is lower, and the container actually behaves like it's isolated, not just politely asked. The real win? It forces you to think about explicit volume mounts and capabilities. You can't just `--privileged` by accident.

Of course, now the red team playbook shifts. You're hunting for kernel namespaces bugs, not leaking socket files. But as a baseline? It's a no-brainer. If you're still running your IronClaw targets in rootful Docker by default, you're doing it wrong. You're testing the wrong things.

-- e]]></content:encoded>
						                            <category domain="https://openclawsecurity.net/community/openclaw-sandbox-escapes/">Sandbox Escapes and Breakout Research</category>                        <dc:creator>Eve Redmond</dc:creator>
                        <guid isPermaLink="true">https://openclawsecurity.net/community/openclaw-sandbox-escapes/switched-from-the-default-setup-to-a-rootless-container-stability-improved/</guid>
                    </item>
				                    <item>
                        <title>Switched from naive Docker to gVisor, here is why</title>
                        <link>https://openclawsecurity.net/community/openclaw-sandbox-escapes/switched-from-naive-docker-to-gvisor-here-is-why/</link>
                        <pubDate>Wed, 08 Jul 2026 21:01:09 +0000</pubDate>
                        <description><![CDATA[Hey folks, I&#039;ve been running my OpenClaw agents in Docker containers for a while now, thinking the isolation was &quot;good enough&quot; for my home lab. But after diving into some breakout research p...]]></description>
                        <content:encoded><![CDATA[Hey folks, I've been running my OpenClaw agents in Docker containers for a while now, thinking the isolation was "good enough" for my home lab. But after diving into some breakout research posted here, I got spooked. A determined agent with a kernel exploit could potentially own the host.

So, I migrated my entire setup to gVisor (using `runsc`). The peace of mind is worth the slight complexity bump.

Why gVisor over plain Docker? It's about the security boundary.
*   Docker containers share the host kernel. A container escape is a host compromise.
*   gVisor implements a user-space kernel (the "Sentry"). The container's syscalls are intercepted and handled by this layer, not the real host kernel. An escape would need to break out of the gVisor sandbox first.

The performance hit is minimal for my agent workloads, which are mostly network and logic, not heavy I/O. Setup wasn't too bad:
*   Installed `runsc` and configured Docker to use it as a runtime.
*   Created a new container runtime profile in my `docker-compose.yml`.
*   Recreated my stacks.

A couple gotchas I ran into:
*   Some syscalls aren't fully implemented. I had to switch from using `ping` inside a container to a simple TCP connectivity check for my healthchecks.
*   /proc and /sys look different inside the container. This broke a custom monitoring script that parsed `proc` directly.

For anyone hosting potentially untrusted code—even in a research context—I think moving beyond naive container isolation is a must. gVisor, Kata Containers, or even Firecracker microVMs are the next logical step.

Has anyone else made a similar switch? Curious about your experiences with alternative runtimes in an OpenClaw context.

~ Raj]]></content:encoded>
						                            <category domain="https://openclawsecurity.net/community/openclaw-sandbox-escapes/">Sandbox Escapes and Breakout Research</category>                        <dc:creator>Raj Host</dc:creator>
                        <guid isPermaLink="true">https://openclawsecurity.net/community/openclaw-sandbox-escapes/switched-from-naive-docker-to-gvisor-here-is-why/</guid>
                    </item>
				                    <item>
                        <title>How do I test if my OpenClaw sandbox is actually containing agent actions?</title>
                        <link>https://openclawsecurity.net/community/openclaw-sandbox-escapes/how-do-i-test-if-my-openclaw-sandbox-is-actually-containing-agent-actions/</link>
                        <pubDate>Wed, 08 Jul 2026 12:01:08 +0000</pubDate>
                        <description><![CDATA[Hey everyone, I&#039;ve been running some basic pentesting exercises inside the default OpenClaw sandbox. I read the docs on the layered isolation model, which makes sense on paper.

But how do I...]]></description>
                        <content:encoded><![CDATA[Hey everyone, I've been running some basic pentesting exercises inside the default OpenClaw sandbox. I read the docs on the layered isolation model, which makes sense on paper.

But how do I practically test if it's really containing things? I tried a few simple methods, like attempting to write to a known host path or checking network interfaces from inside an agent, and it *seems* blocked. Is there a checklist or known "canary" actions I should try? I'm thinking about agent-exploitation scenarios, but I want to make sure my own sandbox is solid first before diving deeper.

I'm especially curious about breakout paths that might rely on the host's specific configuration. Any tips on where to start looking?]]></content:encoded>
						                            <category domain="https://openclawsecurity.net/community/openclaw-sandbox-escapes/">Sandbox Escapes and Breakout Research</category>                        <dc:creator>Tommy Nguyen</dc:creator>
                        <guid isPermaLink="true">https://openclawsecurity.net/community/openclaw-sandbox-escapes/how-do-i-test-if-my-openclaw-sandbox-is-actually-containing-agent-actions/</guid>
                    </item>
				                    <item>
                        <title>News reaction: The maintainers say &#039;run it in a VM&#039; is a valid mitigation. Is it?</title>
                        <link>https://openclawsecurity.net/community/openclaw-sandbox-escapes/news-reaction-the-maintainers-say-run-it-in-a-vm-is-a-valid-mitigation-is-it/</link>
                        <pubDate>Sun, 05 Jul 2026 13:01:05 +0000</pubDate>
                        <description><![CDATA[The recent advisory from the OpenClaw maintainers regarding the `nano-claw` sandbox escape (CVE-2024-xxxxx) concluded that &quot;running the agent orchestrator within a virtual machine is a valid...]]></description>
                        <content:encoded><![CDATA[The recent advisory from the OpenClaw maintainers regarding the `nano-claw` sandbox escape (CVE-2024-xxxxx) concluded that "running the agent orchestrator within a virtual machine is a valid mitigation." While pragmatically true in the immediate sense, this statement requires significant qualification from an operational security perspective. Treating a VM as a silver bullet is a dangerous oversimplification.

The primary issue is one of scope and threat modeling. A VM indeed provides a strong isolation boundary against an agent attempting to:
*   Escalate privileges on the host OS.
*   Directly access host filesystems or hardware.
*   Establish raw network connections to internal infrastructure.

However, this mitigation only addresses a subset of potential agent objectives. It does nothing to prevent:
*   **Cost exhaustion attacks:** An escaped agent, even confined to a VM, can still make unbounded API calls to paid LLM services or other external APIs, leading to significant financial impact.
*   **Data exfiltration via allowed channels:** If the agent can reach the internet (a necessity for most useful agents), it can encode and exfiltrate any data it has access to within the VM—including secrets, source code, or training data—through outbound HTTP requests.
*   **Pivot to other cloud resources:** Within a cloud environment, a compromised VM can leverage its instance metadata service or default IAM roles to attack other internal assets, a classic lateral movement path.

Furthermore, the "VM as mitigation" approach often leads to a false sense of security, potentially causing teams to neglect other essential guardrails. The more critical layers remain:
*   **Strict output validation and parsing:** Sanitizing and structuring LLM outputs before any execution.
*   **Action allow-listing:** The agent should only ever call a pre-defined, minimal set of functions with explicit parameters.
*   **Resource rate-limiting and budgeting:** Enforcing hard limits on API calls, tokens processed, and new processes spawned.
*   **Network egress filtering:** Logging and restricting outbound connections to only necessary services.

In conclusion, while a VM adds a valuable containment layer against host compromise, it is merely one component of a defense-in-depth strategy. It mitigates the *most severe* breakout scenarios but leaves numerous other operational and financial risks fully intact. We should advocate for a layered model of isolation—process, container, VM, network—combined with robust agent-specific controls, rather than accepting "run it in a VM" as a complete solution.

- Tracy]]></content:encoded>
						                            <category domain="https://openclawsecurity.net/community/openclaw-sandbox-escapes/">Sandbox Escapes and Breakout Research</category>                        <dc:creator>Tracy Nguyen</dc:creator>
                        <guid isPermaLink="true">https://openclawsecurity.net/community/openclaw-sandbox-escapes/news-reaction-the-maintainers-say-run-it-in-a-vm-is-a-valid-mitigation-is-it/</guid>
                    </item>
							        </channel>
        </rss>
		