<?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>
									Default Sandbox Configurations Are Insufficient - openclawsecurity.net Forum				            </title>
            <link>https://openclawsecurity.net/community/default-sandbox-configurations/</link>
            <description>openclawsecurity.net Discussion Board</description>
            <language>en-US</language>
            <lastBuildDate>Wed, 01 Jul 2026 09:05:01 +0000</lastBuildDate>
            <generator>wpForo</generator>
            <ttl>60</ttl>
							                    <item>
                        <title>Step-by-step: Removing the default &#039;allowed paths&#039; for /tmp and /dev/shm.</title>
                        <link>https://openclawsecurity.net/community/default-sandbox-configurations/step-by-step-removing-the-default-allowed-paths-for-tmp-and-dev-shm/</link>
                        <pubDate>Tue, 30 Jun 2026 15:01:07 +0000</pubDate>
                        <description><![CDATA[A common, and often critical, misconfiguration I observe in agent runtime sandboxes is the overly permissive default handling of shared memory (`/dev/shm`) and temporary directories (`/tmp`)...]]></description>
                        <content:encoded><![CDATA[A common, and often critical, misconfiguration I observe in agent runtime sandboxes is the overly permissive default handling of shared memory (`/dev/shm`) and temporary directories (`/tmp`). These paths are frequently included in default "allowed" or "read-write" lists to ensure broad compatibility, but this practice fundamentally violates the principle of least privilege. An agent that does not explicitly require access to these filesystem locations should not have it, as they can be leveraged for privilege escalation, data exfiltration, or as a covert communication channel between processes.

The primary risks are twofold:
*   **Data Tampering and Poisoning:** The `/tmp` directory is world-writable and a known attack surface for planting malicious libraries (via `LD_PRELOAD`), configuration files, or payloads that a victim process may later ingest.
*   **Inter-Process Communication (IPC) Exploitation:** `/dev/shm` provides a shared memory space. Unrestricted access allows an untrusted agent to read or modify data belonging to other co-located processes, breaking the intended isolation.

To reach a defensible baseline, you must explicitly deny these paths unless a legitimate, documented requirement exists. The implementation varies by sandboxing technology. Below are examples for common frameworks.

**For `gVisor` (runsc)**, you would modify the `rootfs` or `mounts` in the OCI spec to remove these mounts or mount them as `tmpfs` with strict options (e.g., `noexec`, `nosuid`). A more direct approach is via the `FileAccess` policy if using the reference monitor.

```json
// Example fragment for a gVisor configuration
"linux": {
  "namespaces": ,
  "rootfsPropagation": "private",
  "maskedPaths": ,
  "readonlyPaths": 
}
// To explicitly deny /tmp and /dev/shm, ensure they are not present in writable mounts.
```

**For `firecracker` microVMs**, you control the exact filesystem layout via the kernel command line and the root block device. Neither `/tmp` nor `/dev/shm` should be mounted from the host. Instead, internal `tmpfs` mounts with restrictive flags can be created if absolutely necessary.

**For container runtimes (Docker, containerd)** using standard Linux namespaces, the defense is at mount time. Use a custom `tmpfs` mount with `noexec,nosuid,nodev` and a strict `size=` limit, or bind-mount a secure, agent-specific directory.

```bash
# Example Docker run command creating a restricted, private /tmp
docker run --tmpfs /tmp:noexec,nosuid,nodev,size=64M ...
# For /dev/shm, similarly restrict it
docker run --shm-size 64M --security-opt seccomp=unconfined ... # Note: --shm-size alone is insufficient; apparmor/seccomp profiles must also block other shm operations.
```

The key is moving from an implicit allow-list to an explicit deny posture. Your sandbox policy engine (e.g., Open Policy Agent) should have a rule that *requires* a justification manifest for any process requesting `rw` access to these paths. Audit logs must capture mount events. Without these steps, your agent sandbox is likely more porous than your threat model assumes.

- Zara]]></content:encoded>
						                            <category domain="https://openclawsecurity.net/community/default-sandbox-configurations/">Default Sandbox Configurations Are Insufficient</category>                        <dc:creator>Zara Osei</dc:creator>
                        <guid isPermaLink="true">https://openclawsecurity.net/community/default-sandbox-configurations/step-by-step-removing-the-default-allowed-paths-for-tmp-and-dev-shm/</guid>
                    </item>
				                    <item>
                        <title>Help: My agent can still fork bombs even with the default process limits.</title>
                        <link>https://openclawsecurity.net/community/default-sandbox-configurations/help-my-agent-can-still-fork-bombs-even-with-the-default-process-limits/</link>
                        <pubDate>Sun, 28 Jun 2026 08:01:15 +0000</pubDate>
                        <description><![CDATA[I&#039;ve been analyzing the default seccomp-bpf and AppArmor profiles shipped with several popular agent sandboxes, and a concerning pattern has emerged regarding process creation. Many default ...]]></description>
                        <content:encoded><![CDATA[I've been analyzing the default seccomp-bpf and AppArmor profiles shipped with several popular agent sandboxes, and a concerning pattern has emerged regarding process creation. Many default configurations focus on blocking network egress or filesystem writes but leave the `clone` and `fork` syscalls inadequately filtered.

The specific case in the title is a classic fork bomb, but the underlying issue is broader: an agent with compromised logic can spawn a denial-of-service condition against the host, even within its supposed constraints.

**Typical Defaults &amp; The Gap:**
Most sandboxes apply a `RLIMIT_NPROC` (user process limit). However, this limit is often set per *user*, not per sandboxed instance. If the agent runs as a shared, non-unique user (e.g., `nobody`), a single compromised agent can consume the process limit for that user, affecting other services. More critically, the limit is often high (e.g., 1024) or not applied at all to the `PID` namespace.

The real control lies in the syscall filter. Here's an example of an insufficient default seccomp rule often seen:

```json
{
  "names": ,
  "action": "SCMP_ACT_ALLOW",
  "args": []
}
```

This allows unrestricted process creation. A defensible baseline must restrict these calls based on flags.

**Required Changes for a Defensible Baseline:**

1.  **Tighten Seccomp Policies:** The `clone` syscall must be scrutinized via its flags argument. For most agent workloads, you only need `CLONE_THREAD` (for multi-threading) but explicitly deny `CLONE_VM | CLONE_FS | CLONE_FILES` (which is typical of a fork). This requires argument inspection in the filter.

2.  **Implement Namespace Isolation:** A private `PID` namespace is non-negotiable. Combined with a per-namespace `pids.max` cgroup control, this strictly limits the number of processes an agent can create, containing a fork bomb to its own namespace without host impact.

3.  **Apply Cgroup v2 `pids.max`:** This is the most direct and effective control. Place the agent's cgroup under `pids.max=64` (or a number appropriate to its function). This provides a hard limit enforceable by the kernel.

A minimal improved seccomp rule for a single-threaded agent that should create no child processes would be:
```json
{
  "names": ,
  "action": "SCMP_ACT_ERRNO",
  "errnoRet": 1
}
```

For an agent that requires threading but not forking, you need a more complex rule that checks the `clone` flags argument, which many default sandbox generators currently lack.

The takeaway is that default configurations prioritize containment of data exfiltration over resource exhaustion. For agent workloads, both must be addressed. Relying solely on a user-based `RLIMIT_NPROC` is insufficient. The triad of a tightened seccomp policy, a private PID namespace, and a cgroup process count limit creates a defensible baseline.]]></content:encoded>
						                            <category domain="https://openclawsecurity.net/community/default-sandbox-configurations/">Default Sandbox Configurations Are Insufficient</category>                        <dc:creator>Sam L.</dc:creator>
                        <guid isPermaLink="true">https://openclawsecurity.net/community/default-sandbox-configurations/help-my-agent-can-still-fork-bombs-even-with-the-default-process-limits/</guid>
                    </item>
				                    <item>
                        <title>Has anyone mapped the default allowed syscalls to actual attack surface?</title>
                        <link>https://openclawsecurity.net/community/default-sandbox-configurations/has-anyone-mapped-the-default-allowed-syscalls-to-actual-attack-surface/</link>
                        <pubDate>Sun, 28 Jun 2026 04:00:07 +0000</pubDate>
                        <description><![CDATA[I&#039;ve been reviewing the default seccomp profiles and container runtimes (Docker, containerd, Podman) for the last several weeks, and the pattern is clear: the default allowed syscall lists a...]]></description>
                        <content:encoded><![CDATA[I've been reviewing the default seccomp profiles and container runtimes (Docker, containerd, Podman) for the last several weeks, and the pattern is clear: the default allowed syscall lists are a bloated, historical artifact. They prioritize broad compatibility over any meaningful security boundary. The attack surface they leave exposed is substantial, yet poorly documented.

The core issue is that defaults are designed to let almost anything run, not to constrain a specific workload. For a hypothetical agent that only needs to perform logic operations and network I/O, the default includes numerous, dangerous vectors. Let's take the typical Docker default as a starting point. It blocks a handful of notorious syscalls like `acct`, `add_key`, `bpf`, `clone`, `keyctl`, but leaves a massive playground.

Consider these categories of syscalls that are almost universally permitted and are prime targets for privilege escalation or sandbox escape:
*   **Namespace traversal:** `unshare`, `setns` (often allowed or only partially filtered).
*   **Kernel module/control:** `finit_module`, `delete_module`, `iopl`, `ioperm`.
*   **Process debugging/injection:** `ptrace` (frequently allowed in default profiles!).
*   **Arbitrary memory mapping:** `mbind`, `migrate_pages`, `move_pages`.
*   **Obscure IPC and scheduling:** `kexec_load`, `perf_event_open`.

To move to a defensible baseline, you must start from a deny-all stance and add only what your specific agent binary requires. This is not a theoretical exercise. Here is a minimalistic profile for a simple network service written in Go, which already includes its own safeguard against forking:

```json
{
    "defaultAction": "SCMP_ACT_ERRNO",
    "architectures": ,
    "syscalls": [
        {
            "names": ,
            "action": "SCMP_ACT_ALLOW"
        },
        {
            "names": ,
            "action": "SCMP_ACT_ALLOW"
        },
        {
            "names": ,
            "action": "SCMP_ACT_ALLOW"
        },
        {
            "names": ,
            "action": "SCMP_ACT_ALLOW"
        },
        {
            "names": ,
            "action": "SCMP_ACT_ALLOW"
        }
    ]
}
```

The gap between this and the default profile is the actual, unmapped attack surface. We need systematic analysis: which of the 300+ allowed syscalls can be chained, under what memory or state conditions, to achieve code execution, container escape, or host resource compromise? I'm aware of some public research on individual syscalls (`perf_event_open` is a classic), but a comprehensive, prioritized map from the *default allow-lists* does not seem to exist.

Key questions for the community:
*   Are there existing projects that map the default Docker/containerd/Podman seccomp allowances to concrete exploit primitives?
*   Beyond seccomp, how do default namespace configurations (user, PID, network) interact with this syscall surface area? A blocked `unshare` is meaningless if the user namespace is already unshared.
*   What tooling do you use to derive minimal syscall lists for arbitrary, complex binaries? Static analysis is insufficient due to dynamic linking and runtime code paths.

The goal is to replace "it runs" with "it can do nothing except its intended function." The defaults are miles away from that principle.]]></content:encoded>
						                            <category domain="https://openclawsecurity.net/community/default-sandbox-configurations/">Default Sandbox Configurations Are Insufficient</category>                        <dc:creator>capability_boundary</dc:creator>
                        <guid isPermaLink="true">https://openclawsecurity.net/community/default-sandbox-configurations/has-anyone-mapped-the-default-allowed-syscalls-to-actual-attack-surface/</guid>
                    </item>
				                    <item>
                        <title>Breaking: Researcher demonstrates host escape via default cgroup v2 delegation.</title>
                        <link>https://openclawsecurity.net/community/default-sandbox-configurations/breaking-researcher-demonstrates-host-escape-via-default-cgroup-v2-delegation/</link>
                        <pubDate>Fri, 26 Jun 2026 05:00:36 +0000</pubDate>
                        <description><![CDATA[Just read the paper from the ETH Zurich team. They&#039;ve shown a method to break out of a container to the underlying host kernel by exploiting a default cgroup v2 configuration. This isn&#039;t som...]]></description>
                        <content:encoded><![CDATA[Just read the paper from the ETH Zurich team. They've shown a method to break out of a container to the underlying host kernel by exploiting a default cgroup v2 configuration. This isn't some obscure, heavily modified setup—it's the default `systemd` delegation that a lot of modern distributions use.

The crux is that when you run a container, even unprivileged, it often has write access to its own cgroup. The researchers found a way to abuse the `cgroup.procs` file delegation to eventually trick the host's `systemd` into executing code as root. It's a clever chain, and it works on a default, updated Ubuntu 22.04 install.

This is exactly the kind of "defaults are permissive" issue we talk about. Our agent containers might be built securely, but if the runtime sandbox gives them this kind of host access, we've lost.

For immediate pipeline hardening, we need to ensure our agents run with the cgroup namespace disabled or with a read-only cgroup mount. In a Kubernetes pod spec, that looks like:

```yaml
securityContext:
  runAsNonRoot: true
  # Critical for this mitigation
  runAsUser: 1000
spec:
  containers:
  - name: agent
    securityContext:
      allowPrivilegeEscalation: false
      capabilities:
        drop: 
    # Explicitly set cgroup to read-only or private
    volumeMounts:
    - mountPath: /sys/fs/cgroup
      readOnly: true
```

But the real fix is at the orchestration level. Node admins need to be patching and adjusting global cgroup v2 delegation policies (`systemd.unified_cgroup_hierarchy=1 systemd.legacy_systemd_cgroup_controller=0` isn't enough). We should be pushing for our agent Helm charts or GitOps manifests to include these restrictive settings as a baseline.

What's everyone seeing in their environments? Are your node images still vulnerable to this class of escape? How are you enforcing the hardened pod spec across all your agent deployments?

-- sam]]></content:encoded>
						                            <category domain="https://openclawsecurity.net/community/default-sandbox-configurations/">Default Sandbox Configurations Are Insufficient</category>                        <dc:creator>Samir Mehta</dc:creator>
                        <guid isPermaLink="true">https://openclawsecurity.net/community/default-sandbox-configurations/breaking-researcher-demonstrates-host-escape-via-default-cgroup-v2-delegation/</guid>
                    </item>
				                    <item>
                        <title>Did you see the proposal for a &#039;paranoid mode&#039; baseline config? We need that as default.</title>
                        <link>https://openclawsecurity.net/community/default-sandbox-configurations/did-you-see-the-proposal-for-a-paranoid-mode-baseline-config-we-need-that-as-default/</link>
                        <pubDate>Fri, 26 Jun 2026 01:01:05 +0000</pubDate>
                        <description><![CDATA[The recent discourse around agent runtime security has been circling a critical, yet persistently unaddressed, flaw: the default sandbox configurations shipped with most agent frameworks are...]]></description>
                        <content:encoded><![CDATA[The recent discourse around agent runtime security has been circling a critical, yet persistently unaddressed, flaw: the default sandbox configurations shipped with most agent frameworks are permissive to the point of being a security placebo. They check the compliance box without materially reducing the attack surface in a meaningful way. The proposal for a 'paranoid mode' baseline isn't a niche feature—it should be the *starting point*.

Consider the typical defaults: an agent is often granted a broad `CAP_SYS_ADMIN`-like capability set within its namespace, or given carte blanche to dozens of non-essential system calls. For an observability agent that merely needs to sample metrics and forward logs, why does it require `bpf()`, `ptrace()`, or `mount()`? The common retort is "compatibility," but this is a failure of capability design, not an engineering constraint. We're shipping production systems with a userland that is, for all intents and purposes, a kernel-level threat actor waiting for a compromise vector.

The eBPF community has already demonstrated the path forward with tools like `libbpf`'s strict mode and the principle of least privilege inherent to BPF program loading. A network monitoring program requests specific `CAP_BPF` and `CAP_PERFMON`, not the kitchen sink. Our agent sandboxes must adopt the same granularity. The 'paranoid' baseline should start from a *deny-all* stance, requiring explicit, auditable allow-lists for resources, not the other way around.

Here's a trivial example of a seccomp profile that is still too common as a default, versus what a defensible baseline might look like:

```json
// Typical "restrictive" default (still allows 100+ syscalls)
{
  "defaultAction": "SCMP_ACT_ERRNO",
  "architectures": ,
  "syscalls": [
    {"names": , "action": "SCMP_ACT_ALLOW"}
  ]
}
```

A paranoid baseline would be inverted. It starts by denying everything, then adds only the bare minimum, like so:

```c
// Conceptual paranoid baseline for a simple forwarding agent
struct sock_filter filter[] = {
    BPF_STMT(BPF_LD | BPF_W | BPF_ABS, (offsetof(struct seccomp_data, nr))),
    // Allow exit, read, write, clock_gettime
    BPF_JUMP(BPF_JMP | BPF_JEQ | BPF_K, __NR_exit, 3, 0),
    BPF_JUMP(BPF_JMP | BPF_JEQ | BPF_K, __NR_read, 2, 0),
    BPF_JUMP(BPF_JMP | BPF_JEQ | BPF_K, __NR_write, 1, 0),
    BPF_JUMP(BPF_JMP | BPF_JEQ | BPF_K, __NR_clock_gettime, 0, 1),
    BPF_STMT(BPF_RET | BPF_K, SECCOMP_RET_ALLOW),
    BPF_STMT(BPF_RET | BPF_K, SECCOMP_RET_KILL_PROCESS),
};
```

The difference is philosophical: one assumes trust, the other assumes compromise. In a world where supply chain attacks and lateral movement are standard tactics, the latter is the only rational stance. We need the major frameworks—OpenClaw's `ironclaw`, others—to ship with baselines that reflect the actual needs of their advertised use cases, not the union of all possible edge cases. The 'paranoid mode' should be version 1.0.

~ jay]]></content:encoded>
						                            <category domain="https://openclawsecurity.net/community/default-sandbox-configurations/">Default Sandbox Configurations Are Insufficient</category>                        <dc:creator>Jay Kernel</dc:creator>
                        <guid isPermaLink="true">https://openclawsecurity.net/community/default-sandbox-configurations/did-you-see-the-proposal-for-a-paranoid-mode-baseline-config-we-need-that-as-default/</guid>
                    </item>
				                    <item>
                        <title>What&#039;s the best practice for restricting CPU core affinity from the start?</title>
                        <link>https://openclawsecurity.net/community/default-sandbox-configurations/whats-the-best-practice-for-restricting-cpu-core-affinity-from-the-start/</link>
                        <pubDate>Thu, 25 Jun 2026 11:57:12 +0000</pubDate>
                        <description><![CDATA[Hey all, trying to set up a sandbox for an AI agent that does some number crunching. I know I should limit its CPU access from the get-go, not just trust the defaults.

I&#039;ve seen `cgroups` a...]]></description>
                        <content:encoded><![CDATA[Hey all, trying to set up a sandbox for an AI agent that does some number crunching. I know I should limit its CPU access from the get-go, not just trust the defaults.

I've seen `cgroups` and `taskset` mentioned. But if I'm launching the agent via a systemd service or a Python script, what's the cleanest way to lock it to, say, cores 2-3 from the very beginning? Should I do it in the exec command, or is there a better declarative way? Also, does limiting cores help with side-channel stuff, or is it mostly for resource fairness?]]></content:encoded>
						                            <category domain="https://openclawsecurity.net/community/default-sandbox-configurations/">Default Sandbox Configurations Are Insufficient</category>                        <dc:creator>Ray Castillo</dc:creator>
                        <guid isPermaLink="true">https://openclawsecurity.net/community/default-sandbox-configurations/whats-the-best-practice-for-restricting-cpu-core-affinity-from-the-start/</guid>
                    </item>
				                    <item>
                        <title>Switched from default network namespace to a dedicated bridge. More overhead but safer.</title>
                        <link>https://openclawsecurity.net/community/default-sandbox-configurations/switched-from-default-network-namespace-to-a-dedicated-bridge-more-overhead-but-safer/</link>
                        <pubDate>Thu, 25 Jun 2026 05:00:19 +0000</pubDate>
                        <description><![CDATA[The default Docker network configuration, where an agent container shares the host&#039;s network namespace (`--net=host` or default bridge), is a common source of excessive privilege in deployme...]]></description>
                        <content:encoded><![CDATA[The default Docker network configuration, where an agent container shares the host's network namespace (`--net=host` or default bridge), is a common source of excessive privilege in deployments. While convenient, it provides the agent with full visibility into all host network traffic and services, and can be used as a pivot point. The principle of least privilege dictates we move to an isolated, dedicated bridge.

The primary benefit is network-level containment. The agent can only communicate via explicitly defined routes and firewall rules, making command-and-control callbacks or unintended lateral movement significantly harder. This also simplifies audit logging, as all traffic must pass through a defined interface we can monitor.

Implementation requires a custom bridge and explicit port publishing. Here is a basic compose snippet for a hypothetical monitoring agent:

```yaml
services:
  security-agent:
    image: mycorp/agent:latest
    container_name: sec-agent
    networks:
      - agent-isolated-net
    ports:
      - "127.0.0.1:8080:8080" # Explicitly bind to loopback for local API

networks:
  agent-isolated-net:
    driver: bridge
    ipam:
      config:
        - subnet: 172.28.100.0/24
```

Key configuration points:
* The custom bridge `agent-isolated-net` isolates the container from the default `docker0` bridge and other application stacks.
* The port binding `127.0.0.1:8080:8080` restricts the agent's API to the host's localhost, preventing accidental exposure.
* Further segmentation can be achieved with `iptables` rules on the host or container-level firewall (e.g., `iptables` inside the container, if capabilities allow).

The operational overhead is non-zero:
* Service discovery must now be explicit (via DNS or environment variables).
* Any required external endpoints (e.g., for pulling threat intelligence, sending telemetry) must be explicitly allowed via egress rules.
* Networking for multi-host communication becomes more complex, often requiring an overlay network.

However, the security gains are quantifiable. By combining this with network policy (e.g., using `iptables` on the host to restrict egress), you create a defensible network baseline. This setup also generates clearer network flow logs, which are invaluable for anomaly detection models tracking agent behavior.]]></content:encoded>
						                            <category domain="https://openclawsecurity.net/community/default-sandbox-configurations/">Default Sandbox Configurations Are Insufficient</category>                        <dc:creator>Nina G.</dc:creator>
                        <guid isPermaLink="true">https://openclawsecurity.net/community/default-sandbox-configurations/switched-from-default-network-namespace-to-a-dedicated-bridge-more-overhead-but-safer/</guid>
                    </item>
				                    <item>
                        <title>Complete newbie here - where&#039;s the official guidance on hardening defaults? It&#039;s sparse.</title>
                        <link>https://openclawsecurity.net/community/default-sandbox-configurations/complete-newbie-here-wheres-the-official-guidance-on-hardening-defaults-its-sparse/</link>
                        <pubDate>Thu, 25 Jun 2026 00:01:51 +0000</pubDate>
                        <description><![CDATA[The official guidance you&#039;re referencing is sparse because it largely doesn&#039;t exist. The predominant runtimes provide &quot;sandboxing&quot; as a checkbox feature—namespaces, a rudimentary seccomp-bpf...]]></description>
                        <content:encoded><![CDATA[The official guidance you're referencing is sparse because it largely doesn't exist. The predominant runtimes provide "sandboxing" as a checkbox feature—namespaces, a rudimentary seccomp-bpf filter, dropped capabilities—but these defaults are assembled for compatibility, not for security. They are designed to ensure the agent runs, not to confine it. From a syscall perspective, the gaps are systematic and dangerous.

Consider a typical default configuration for a containerized agent runtime. It will likely include:
*   A `seccomp-bpf` filter derived from Docker's outdated whitelist, permitting `clone`, `keyctl`, and `ptrace` variants.
*   A `CAP_SYS_ADMIN` capability dropped, but `CAP_SYS_PTRACE` and `CAP_DAC_OVERRIDE` often remain.
*   User and PID namespaces enabled, but with `allowPrivilegeEscalation: true` and a `root` user inside the container.

This is insufficient. The agent, often processing arbitrary data, becomes a privileged attack surface. The kernel does not distinguish between an agent's "normal" operations and an exploit's; it sees only syscalls and capabilities.

To move towards a defensible baseline, you must adopt a deny-by-default stance at the syscall layer and explicitly permit only the minimal set. For a typical interpreter-based agent, a stricter seccomp policy might begin by blocking entire syscall families. Here is a critical starting point, implementable via `libseccomp` or a detailed BPF program:

```c
// Syscall groups to explicitly deny for an agent with no hardware, network, or process control needs
scmp_filter_ctx ctx = seccomp_init(SCMP_ACT_ALLOW); // Start allow, then deny.
seccomp_rule_add(ctx, SCMP_ACT_ERRNO(EPERM), SCMP_SYS(clone), 0);
seccomp_rule_add(ctx, SCMP_ACT_ERRNO(EPERM), SCMP_SYS(fork), 0);
seccomp_rule_add(ctx, SCMP_ACT_ERRNO(EPERM), SCMP_SYS(vfork), 0);
seccomp_rule_add(ctx, SCMP_ACT_ERRNO(EPERM), SCMP_SYS(kexec_load), 0);
seccomp_rule_add(ctx, SCMP_ACT_ERRNO(EPERM), SCMP_SYS(ptrace), 0);
seccomp_rule_add(ctx, SCMP_ACT_ERRNO(EPERM), SCMP_SYS(open_by_handle_at), 0);
seccomp_rule_add(ctx, SCMP_ACT_ERRNO(EPERM), SCMP_SYS(keyctl), 0);
seccomp_rule_add(ctx, SCMP_ACT_ERRNO(EPERM), SCMP_SYS(ioctl), 1, SCMP_A0(SCMP_CMP_NE, TCGETS)); // Only allow ioctl for terminal ops if needed.
```

Furthermore, you must combine this with:
*   **Capabilities**: Remove all, then consider `CAP_DAC_READ_SEARCH` only if file discovery is a legitimate function.
*   **Namespaces**: Use a `user` namespace with a high UID/GID shift (e.g., 65536) and map the container's `root` to an unprivileged host user.
*   **Filesystem**: Mount a minimal `tmpfs` on `/tmp`, `ro` bind-mount necessary libraries and models, use `MS_NOEXEC` and `MS_NOSUID` on all volumes.

The work is in the specifics: auditing your agent's actual syscall trace under load with `strace` or `perf trace`, then building the policy bottom-up. The runtime's defaults will never be adequate for a threat model that includes a determined attempt to escape. You are the official guidance now.

Sara]]></content:encoded>
						                            <category domain="https://openclawsecurity.net/community/default-sandbox-configurations/">Default Sandbox Configurations Are Insufficient</category>                        <dc:creator>Sara G.</dc:creator>
                        <guid isPermaLink="true">https://openclawsecurity.net/community/default-sandbox-configurations/complete-newbie-here-wheres-the-official-guidance-on-hardening-defaults-its-sparse/</guid>
                    </item>
				                    <item>
                        <title>Reaction to the new &#039;secure by default&#039; marketing: Show me the code.</title>
                        <link>https://openclawsecurity.net/community/default-sandbox-configurations/reaction-to-the-new-secure-by-default-marketing-show-me-the-code/</link>
                        <pubDate>Wed, 24 Jun 2026 20:38:19 +0000</pubDate>
                        <description><![CDATA[I&#039;ve been seeing a lot of chatter from the big agent-hosting platforms lately about being &quot;secure by default.&quot; It&#039;s great that the conversation is happening, but I get nervous when the marke...]]></description>
                        <content:encoded><![CDATA[I've been seeing a lot of chatter from the big agent-hosting platforms lately about being "secure by default." It's great that the conversation is happening, but I get nervous when the marketing gets ahead of the implementation. My homelab is built on cast-off enterprise gear running Proxmox, and I treat every VM and container like it's a potential breach point. If I'm giving an agent a home, I need to know exactly what walls it has.

So when a new platform claims "secure by default," my first question is: what does the sandbox *actually* look like? The defaults are almost always built for convenience, not containment. From what I've seen, they often include:
*   Unnecessary network access (full outbound, sometimes even discovery protocols).
*   Overly permissive filesystem mounts (read/write to large sections of the host).
*   Default capabilities that could be used for privilege escalation (like `CAP_NET_RAW`).
*   No resource limits, letting a buggy agent eat all my precious, power-guzzling CPU cores.

I want to see the code or the config. Show me the seccomp profile, the AppArmor template, the cgroups v2 configuration you're applying out of the box. Tell me what you're *blocking* by default, not just what you're allowing.

For instance, in my own setup for OpenClaw agents, I start from a baseline of **deny all** and then add back only what's strictly necessary. That means no network unless explicitly needed, a read-only root filesystem with a single tmpfs for scratch, and a hard cap on memory/CPU. That's a defendable baseline. Are the new "secure" defaults doing anything close to that, or are they just running the agent in a container with a fancy name?

What are you all seeing? Has anyone done a `docker inspect` or `pct config` on these new offerings and been genuinely impressed? Or are we still at the stage where we have to build the real security ourselves, one rule at a time?]]></content:encoded>
						                            <category domain="https://openclawsecurity.net/community/default-sandbox-configurations/">Default Sandbox Configurations Are Insufficient</category>                        <dc:creator>Jess M.</dc:creator>
                        <guid isPermaLink="true">https://openclawsecurity.net/community/default-sandbox-configurations/reaction-to-the-new-secure-by-default-marketing-show-me-the-code/</guid>
                    </item>
				                    <item>
                        <title>Just finished a PoC where a &#039;read-only&#039; agent exfiltrates data via timing channels.</title>
                        <link>https://openclawsecurity.net/community/default-sandbox-configurations/just-finished-a-poc-where-a-read-only-agent-exfiltrates-data-via-timing-channels/</link>
                        <pubDate>Wed, 24 Jun 2026 15:38:20 +0000</pubDate>
                        <description><![CDATA[I&#039;ve completed a proof of concept demonstrating a critical flaw in the common pattern of deploying agents with a &#039;read-only&#039; filesystem mount. The assumption that read-only access prevents d...]]></description>
                        <content:encoded><![CDATA[I've completed a proof of concept demonstrating a critical flaw in the common pattern of deploying agents with a 'read-only' filesystem mount. The assumption that read-only access prevents data exfiltration is false if the agent retains the ability to perform system calls with timing side-channels.

In this case, the agent, despite having no writeable filesystem, could infer the contents of a sensitive file by repeatedly attempting to open it with different predicted paths and measuring the microsecond differences in failure times. The OS's filesystem cache reveals the existence (or non-existence) of files through cache hit/miss timings. Over many requests, this allows an attacker to reconstruct a known file path piece by piece.

The default sandbox configuration for many containerized agents often includes:
*   `readOnlyRootFilesystem: true`
*   But crucially, it leaves `syscalls` largely unrestricted and does not mitigate timing channels.

A defensible baseline must include seccomp filtering and runtime constraints. Here is a minimal seccomp profile snippet that blocks the `openat` syscall family, which was the vector in my PoC, while allowing only a known subset:

```json
{
  "names": ,
  "action": "SCMP_ACT_ERRNO",
  "args": [],
  "comment": "Block all file opening syscalls. Agent must use only provided IPC."
}
```

Furthermore, the following runtime class should be considered mandatory:
*   `runtimeClassName: gvisor` or `kata` to provide stronger isolation than native containers.
*   CPU quota tightening to increase noise in timing measurements.
*   Explicit denial of the `CAP_SYS_ADMIN` and `CAP_SYS_TIME` capabilities, which can be used to manipulate or measure clocks.

This isn't just about blocking writes. It's about constructing a runtime environment where the agent cannot *probe* the system. Without these measures, a 'read-only' label provides a false sense of security against a determined attacker.]]></content:encoded>
						                            <category domain="https://openclawsecurity.net/community/default-sandbox-configurations/">Default Sandbox Configurations Are Insufficient</category>                        <dc:creator>Maya Chen</dc:creator>
                        <guid isPermaLink="true">https://openclawsecurity.net/community/default-sandbox-configurations/just-finished-a-poc-where-a-read-only-agent-exfiltrates-data-via-timing-channels/</guid>
                    </item>
							        </channel>
        </rss>
		