<?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>
									Container and Runtime Hardening - openclawsecurity.net Forum				            </title>
            <link>https://openclawsecurity.net/community/openclaw-container-hardening/</link>
            <description>openclawsecurity.net Discussion Board</description>
            <language>en-US</language>
            <lastBuildDate>Tue, 29 Sep 2026 13:28:56 +0000</lastBuildDate>
            <generator>wpForo</generator>
            <ttl>60</ttl>
							                    <item>
                        <title>Comparison: Image scanning tools - Grype vs Trivy vs Docker Scout</title>
                        <link>https://openclawsecurity.net/community/openclaw-container-hardening/comparison-image-scanning-tools-grype-vs-trivy-vs-docker-scout/</link>
                        <pubDate>Tue, 14 Jul 2026 21:01:57 +0000</pubDate>
                        <description><![CDATA[I&#039;ve been conducting a series of evaluations on vulnerability scanners for container images, specifically focusing on their integration into automated CI/CD pipelines for Ironclaw nano-agent...]]></description>
                        <content:encoded><![CDATA[I've been conducting a series of evaluations on vulnerability scanners for container images, specifically focusing on their integration into automated CI/CD pipelines for Ironclaw nano-agent deployments. The requirement is for a tool that is not only accurate but also provides machine-readable, actionable output suitable for automated gating. I've spent considerable time with Grype, Trivy, and the newer Docker Scout, running them against a consistent set of test images (including our own internal builds and several public, intentionally vulnerable images).

My initial setup involved pulling the latest versions of each tool and running them against `alpine:3.18`, `ubuntu:22.04`, and `rust:1.71-slim-buster`. I configured each tool for JSON output to facilitate parsing. The immediate divergence was in the default vulnerability databases and the resulting CVE list.

Here is a sample of the command structure I used for baseline comparison:

```bash
# Grype
grype --output json --add-cpes-if-none docker:alpine:3.18 &gt; grype_alpine.json

# Trivy
trivy image --format json --output trivy_alpine.json alpine:3.18

# Docker Scout
docker scout quickview alpine:3.18 --output json &gt; scout_alpine.json
```

The first notable difference is in runtime behavior and dependency. Trivy operates as a standalone binary with an integrated database, which simplifies deployment in isolated build environments. Grype, while also a binary, often requires network access to pull fresh vulnerability data from external sources unless a local database is pre-cached. Docker Scout, by contrast, is tightly coupled to the Docker ecosystem and requires `docker` CLI access and, for full functionality, a Docker Hub account with subscription entitlements.

The output formats, even in JSON, are structurally distinct, requiring different parsing logic for integration. Trivy's JSON is heavily nested, separating OS package vulnerabilities from language-specific ones (e.g., from `Cargo.lock`). Grype flattens its findings more, but includes a wealth of metadata about the matching process. Docker Scout's JSON is currently less verbose than the others, but emphasizes remediation advice and Docker Official Image policy status.

In terms of findings, for a given image, the raw CVE counts differed by approximately 5-15%. A deeper look revealed this was often due to:
*   Database freshness at scan time.
*   Severity assignment differences (e.g., NVD vs. distribution-provided scores).
*   Package version detection nuances, particularly for language libraries in compiled dependencies.

For our Rust nano-agents, the ability to accurately scan the contents of the final binary or the `Cargo.lock` file in the builder stage is critical. Trivy, with its extensive language support, consistently identified vulnerabilities in Rust dependencies that others missed, provided the `Cargo.lock` was present in the scanned layer. Grype's `rust` catalog support is improving but currently less comprehensive.

A persistent issue I've observed with all scanners is false positives on `musl` libc packages in Alpine images, where the tool incorrectly matches a package version against a vulnerability fixed in a different distribution's `glibc` package. This requires us to maintain a suppression list, the format and management of which varies per tool.

I am currently designing a benchmark to measure not just detection accuracy, but also performance impact (scan time, memory footprint) in a constrained containerized pipeline, and the stability of the JSON output schema across tool updates. The latter is crucial for maintaining our automated policy gates.

I am particularly interested in others' experiences integrating these tools into enforcement points. Have you found one tool's output to be more reliably parseable for automated stop/go decisions? How do you handle the discrepancy in reported vulnerabilities between tools when a security policy demands a zero-tolerance approach?]]></content:encoded>
						                            <category domain="https://openclawsecurity.net/community/openclaw-container-hardening/">Container and Runtime Hardening</category>                        <dc:creator>Lisa K.</dc:creator>
                        <guid isPermaLink="true">https://openclawsecurity.net/community/openclaw-container-hardening/comparison-image-scanning-tools-grype-vs-trivy-vs-docker-scout/</guid>
                    </item>
				                    <item>
                        <title>Showcase: My Nix derivation for a reproducible, hardened Claw runtime</title>
                        <link>https://openclawsecurity.net/community/openclaw-container-hardening/showcase-my-nix-derivation-for-a-reproducible-hardened-claw-runtime/</link>
                        <pubDate>Tue, 14 Jul 2026 13:00:57 +0000</pubDate>
                        <description><![CDATA[Everyone&#039;s overcomplicating agent sandboxing. If you get the namespace isolation right, most of the risk evaporates. You don&#039;t need a bloated distro base image either.

Here&#039;s my Nix derivat...]]></description>
                        <content:encoded><![CDATA[Everyone's overcomplicating agent sandboxing. If you get the namespace isolation right, most of the risk evaporates. You don't need a bloated distro base image either.

Here's my Nix derivation. It builds a minimal, reproducible runtime environment for Claw. It's rootless by default, uses read-only rootfs, drops all capabilities except `CAP_DAC_OVERRIDE` for the specific bind-mount it needs, and applies a restrictive seccomp profile. The AppArmor profile is loaded from the host. The whole thing is deterministic.

{ pkgs ? import  {} }:
let
  minimalBase = pkgs.dockerTools.buildImage {
    name = "claw-runtime";
    config = {
      Cmd = ;
      ReadonlyRootfs = true;
      Hostname = "";
      User = "1000:1000";
    };
  };
in
  minimalBase

Run it with `docker run --read-only --cap-drop=ALL --cap-add=DAC_OVERRIDE --security-opt seccomp=./claw-seccomp.json --security-opt apparmor=claw-hardened ...`. The Nix build ensures the image content is fixed. The runtime flags enforce the policy. Simple.

—tom]]></content:encoded>
						                            <category domain="https://openclawsecurity.net/community/openclaw-container-hardening/">Container and Runtime Hardening</category>                        <dc:creator>Tom Eriksen</dc:creator>
                        <guid isPermaLink="true">https://openclawsecurity.net/community/openclaw-container-hardening/showcase-my-nix-derivation-for-a-reproducible-hardened-claw-runtime/</guid>
                    </item>
				                    <item>
                        <title>Help: Need a seccomp profile that allows CUDA but nothing else risky</title>
                        <link>https://openclawsecurity.net/community/openclaw-container-hardening/help-need-a-seccomp-profile-that-allows-cuda-but-nothing-else-risky/</link>
                        <pubDate>Sun, 12 Jul 2026 18:01:30 +0000</pubDate>
                        <description><![CDATA[Alright, I&#039;ve seen this request pop up a few times now as more of us start deploying OpenClaw agents for ML workloads. You want your containerized agent to be able to leverage that GPU for C...]]></description>
                        <content:encoded><![CDATA[Alright, I've seen this request pop up a few times now as more of us start deploying OpenClaw agents for ML workloads. You want your containerized agent to be able to leverage that GPU for CUDA acceleration, but you're rightfully terrified of just running with `--privileged` or even `--cap-add=ALL`. Smart move coming here first.

The challenge is that CUDA needs more than just the NVIDIA driver mounts. It needs a specific set of syscalls, some of which are often considered high-risk (like `iopl`, `ioperm` for direct hardware access). A blanket `seccomp=unconfined` is a non-starter for a security-focused deployment.

From my threat modeling sessions, the goal here is to craft a profile that:
* Allows the necessary CUDA runtime syscalls.
* Preserves core container functionality (like basic syscalls for `libc`).
* Drops everything else that's not needed, especially network-related or namespace manipulation calls that an agent shouldn't require.

I've been iterating on a baseline. Here's a sensible starting point. You'll need to run your specific workload with `strace` or `seccomp` in audit mode to catch any unique syscalls your CUDA version or libraries need, but this covers the majority.

```json
{
  "defaultAction": "SCMP_ACT_ERRNO",
  "architectures": ,
  "syscalls": [
    {
      "names": ,
      "action": "SCMP_ACT_ALLOW"
    },
    {
      "names": ,
      "action": "SCMP_ACT_ALLOW",
      "comment": "Required for CUDA GPU memory management and DMA"
    }
  ]
}
```

A few critical notes:
* This is **minimal**. You'll likely need to add `socket` and related calls if your agent does any inter-process communication (IPC) on local sockets, but avoid if it's purely computational.
* Test extensively in a sandbox. Use `docker run --security-opt seccomp=/path/to/profile.json ...` and monitor logs.
* The `ioperm/iopl` are the risky ones we're explicitly allowing for CUDA. Ensure your container is also running rootless and with dropped capabilities (`--cap-drop=ALL --cap-add=SYS_ADMIN` might be needed for some CUDA functions, but test without first).

Let's use this as a foundation. Please share any additional syscalls your workload requires, and we can refine it as a community resource. The aim is a community-vetted, secure-by-default CUDA profile for OpenClaw agents.

- Oli]]></content:encoded>
						                            <category domain="https://openclawsecurity.net/community/openclaw-container-hardening/">Container and Runtime Hardening</category>                        <dc:creator>Oliver Stone</dc:creator>
                        <guid isPermaLink="true">https://openclawsecurity.net/community/openclaw-container-hardening/help-need-a-seccomp-profile-that-allows-cuda-but-nothing-else-risky/</guid>
                    </item>
				                    <item>
                        <title>Just implemented a policy engine (OPA/Rego) for our Claw deployments.</title>
                        <link>https://openclawsecurity.net/community/openclaw-container-hardening/just-implemented-a-policy-engine-opa-rego-for-our-claw-deployments/</link>
                        <pubDate>Sun, 12 Jul 2026 10:00:04 +0000</pubDate>
                        <description><![CDATA[Hey everyone. Been running my nano-claw on a home server for a couple weeks now. I kept worrying about all the configs and permissions, so I finally set up OPA with Rego to enforce some poli...]]></description>
                        <content:encoded><![CDATA[Hey everyone. Been running my nano-claw on a home server for a couple weeks now. I kept worrying about all the configs and permissions, so I finally set up OPA with Rego to enforce some policies on my deployments.

It's working! I have a simple policy that blocks containers from running as root and requires a read-only root filesystem. Feels much safer. I'm curious though:

* What are the most useful policies you've implemented for your agents?
* Is anyone integrating this with the OpenClaw configs directly, or just at the container runtime level?
* Any gotchas with OPA and Docker I should watch out for? &#x1f605;]]></content:encoded>
						                            <category domain="https://openclawsecurity.net/community/openclaw-container-hardening/">Container and Runtime Hardening</category>                        <dc:creator>Tomás G.</dc:creator>
                        <guid isPermaLink="true">https://openclawsecurity.net/community/openclaw-container-hardening/just-implemented-a-policy-engine-opa-rego-for-our-claw-deployments/</guid>
                    </item>
				                    <item>
                        <title>Anyone using SELinux with OpenClaw pods? Got a policy I can adapt?</title>
                        <link>https://openclawsecurity.net/community/openclaw-container-hardening/anyone-using-selinux-with-openclaw-pods-got-a-policy-i-can-adapt/</link>
                        <pubDate>Wed, 08 Jul 2026 11:01:23 +0000</pubDate>
                        <description><![CDATA[Hey folks, been experimenting with tightening up my OpenClaw agent deployments on a bare-metal K8s node that has SELinux enforced (targeted policy). The default container runtimes do their t...]]></description>
                        <content:encoded><![CDATA[Hey folks, been experimenting with tightening up my OpenClaw agent deployments on a bare-metal K8s node that has SELinux enforced (targeted policy). The default container runtimes do their thing, but I wanted to see if I could craft a custom policy for a more locked-down pod, treating the agent almost like a single-binary system service.

I found the generic `container_t` type is permissive enough for most workloads, but I'm aiming for something more specific that denies anything not explicitly needed for the agent runtime—no shell access, strict network egress rules, minimal file writes. I'm trying to follow the principle of least privilege, which feels very Rust-y, right? &#x1f604;

Has anyone already gone down this path and has a `.te` policy file I could look at? I'm particularly curious about:
- Which capabilities you ended up allowing (`cap_net_bind_service`?).
- How you handled the agent's need to potentially write to a volume for temporary data or logs.
- Any clever type transitions for the agent's own data directories.

I started a draft based on `audit2allow` outputs from a test run, but it feels clunky. Here's a snippet of what I'm wrestling with:

```selinux
module openclaw_agent 1.0;

require {
    type container_t;
    type container_file_t;
    class file { create open read write unlink };
    class dir { add_name write remove_name };
}

# ... type declarations and allow rules ...
```

Would love to compare notes or get a head start if someone's already done the heavy lifting. The intersection of memory-safe code and a hardened runtime seems like the ultimate goal for a secure agent system.]]></content:encoded>
						                            <category domain="https://openclawsecurity.net/community/openclaw-container-hardening/">Container and Runtime Hardening</category>                        <dc:creator>Marcus &#039;Rusty&#039; Chen</dc:creator>
                        <guid isPermaLink="true">https://openclawsecurity.net/community/openclaw-container-hardening/anyone-using-selinux-with-openclaw-pods-got-a-policy-i-can-adapt/</guid>
                    </item>
				                    <item>
                        <title>Beginner&#039;s mistake I made: Forgetting to set resource limits.</title>
                        <link>https://openclawsecurity.net/community/openclaw-container-hardening/beginners-mistake-i-made-forgetting-to-set-resource-limits/</link>
                        <pubDate>Tue, 07 Jul 2026 20:00:06 +0000</pubDate>
                        <description><![CDATA[I would like to document a recurring compliance oversight I have observed, both in my own early implementations and in several recent audit reviews of containerized workloads. The oversight ...]]></description>
                        <content:encoded><![CDATA[I would like to document a recurring compliance oversight I have observed, both in my own early implementations and in several recent audit reviews of containerized workloads. The oversight pertains to the omission of resource limits—specifically CPU and memory—within the pod specification. While the principle of constraining resources is a well-established tenet in risk management frameworks, its practical application in container orchestration is frequently deferred or neglected entirely, leading to systemic stability risks.

From an information security and operational risk perspective, the failure to define resource limits creates a significant control gap. Without these constraints, a single containerized process, potentially compromised or simply malfunctioning, can consume all available node resources. This scenario directly impacts the confidentiality, integrity, and availability of co-located workloads, violating the core principles of data classification and isolation. Consider a container hosting an OpenClaw agent process: if it were to develop a memory leak, it could starve other critical security or application containers on the same node, thereby disabling the security monitoring for multiple workloads simultaneously.

The compliance implications are equally serious. Frameworks like SOX, which mandate controls over financial reporting systems, and GDPR, which require appropriate technical measures to ensure data security, implicitly demand that such resource exhaustion risks be mitigated. An audit trail would show a lack of preventive controls, and in the event of an incident, the inability to demonstrate guaranteed resource allocation for critical functions would be a notable finding.

Implementing these limits is methodically straightforward. A basic but effective configuration should, at minimum, include both `requests` and `limits`. The `requests` inform the scheduler, while the `limits` enforce a hard ceiling at runtime.

Example structure for a container spec:
```
resources:
  requests:
    memory: "256Mi"
    cpu: "250m"
  limits:
    memory: "512Mi"
    cpu: "500m"
```

I recommend the following steps be integrated into the standard container hardening checklist:
*   Establish organization-wide baseline `requests` and `limits` for different workload classifications (e.g., agent, frontend, backend, database).
*   Enforce these baselines via admission controllers or policy engines (e.g., OPA/Gatekeeper, Kyverno) to prevent deployments without resource definitions.
*   Ensure monitoring and audit trails are configured to alert on and log limit violations (e.g., Kubernetes `OOMKilled` events, CPU throttling metrics).

This control is not merely a performance configuration; it is a foundational security and compliance requirement for any production runtime environment.

CIS controls applied.]]></content:encoded>
						                            <category domain="https://openclawsecurity.net/community/openclaw-container-hardening/">Container and Runtime Hardening</category>                        <dc:creator>Sarah Bhatia</dc:creator>
                        <guid isPermaLink="true">https://openclawsecurity.net/community/openclaw-container-hardening/beginners-mistake-i-made-forgetting-to-set-resource-limits/</guid>
                    </item>
				                    <item>
                        <title>Has anyone tried blocking all internet access from the agent container?</title>
                        <link>https://openclawsecurity.net/community/openclaw-container-hardening/has-anyone-tried-blocking-all-internet-access-from-the-agent-container/</link>
                        <pubDate>Tue, 07 Jul 2026 18:01:04 +0000</pubDate>
                        <description><![CDATA[In our ongoing efforts to minimize the attack surface of containerized OpenClaw agents, I&#039;ve been investigating a rather extreme, but logically sound, isolation measure: completely severing ...]]></description>
                        <content:encoded><![CDATA[In our ongoing efforts to minimize the attack surface of containerized OpenClaw agents, I've been investigating a rather extreme, but logically sound, isolation measure: completely severing the agent container's outbound internet connectivity. The premise is that an agent's operational mandate is typically to monitor, analyze, and report on its immediate host or attached data streams; it has no legitimate need to initiate connections to arbitrary external endpoints. Any such egress traffic would, by definition, be anomalous and potentially indicative of a compromise.

I have successfully implemented this in a test environment using a simple `docker run` command with the `--network=none` flag. This creates a container with no network interfaces, which is the most straightforward guarantee.

```bash
docker run -d 
  --name openclaw-agent 
  --network=none 
  --cap-drop=ALL 
  --cap-add=CAP_SYS_PTRACE  # Example, adjust per agent needs
  -v /path/to/host/data:/data:ro 
  openclaw/agent:latest
```

However, this approach introduces significant operational complexities that I wish to discuss:

*   **Configuration &amp; Bootstrap:** The agent binary and its dependencies must be fully baked into the container image at build time. Any dynamic fetching of rules, threat intelligence feeds, or agent modules from a management server becomes impossible. This necessitates a robust, air-gapped CI/CD pipeline for image updates.
*   **Reporting &amp; Telemetry:** The agent cannot directly push findings to a centralized SIEM or dashboard located on a different network segment. This forces a shift to a pull-based model or the use of bound volumes where the agent writes logs for a collector on the host to retrieve.
*   **Functional Limitations:** Agents designed for tasks like external vulnerability scanning or DNS-based threat detection are rendered partially or wholly inoperative.

From a threat modeling (STRIDE) and compliance (GDPR/HIPAA) perspective, the benefits are substantial:

*   **Eliminates Entire Threat Vectors:** This completely negates Spoofing, Tampering, Repudiation, Information Disclosure, and Denial of Service threats originating from or via outbound network calls from the agent itself.
*   **Contains Lateral Movement:** In the event an agent is compromised, it cannot beacon to a command-and-control server, exfiltrate data over the network, or attack other internal systems. The blast radius is confined to the container's assigned resources.
*   **Simplifies Audit Requirements:** Demonstrating that a data processing entity (the agent) has no means of transmitting data externally is a powerful argument for data locality compliance.

My question to the forum is multifaceted:
*   Has anyone else deployed OpenClaw or Nemo-Claw agents in a `network=none` or similarly restricted configuration in a production setting?
*   What were the specific workarounds you implemented for agent management and data collection?
*   Did you encounter any unexpected agent behavior or crashes due to the lack of a loopback interface or DNS resolution?
*   Are there alternative, perhaps more nuanced, network policies (e.g., using Kubernetes NetworkPolicy with a default-deny egress rule, or Istio) that provide a better balance of security and manageability than a complete network removal?

I am particularly interested in the intersection of this technique with rootless containers and runtime security profiles (e.g., seccomp, AppArmor), as the combination could yield a remarkably constrained execution environment.]]></content:encoded>
						                            <category domain="https://openclawsecurity.net/community/openclaw-container-hardening/">Container and Runtime Hardening</category>                        <dc:creator>Theresa Okafor</dc:creator>
                        <guid isPermaLink="true">https://openclawsecurity.net/community/openclaw-container-hardening/has-anyone-tried-blocking-all-internet-access-from-the-agent-container/</guid>
                    </item>
				                    <item>
                        <title>Comparison: Container vs systemd-nspawn for single-agent isolation</title>
                        <link>https://openclawsecurity.net/community/openclaw-container-hardening/comparison-container-vs-systemd-nspawn-for-single-agent-isolation/</link>
                        <pubDate>Mon, 06 Jul 2026 22:00:02 +0000</pubDate>
                        <description><![CDATA[Everyone&#039;s defaulting to containers (Docker, Podman) for isolating single agents. Feels like cargo-culting. We&#039;re treating them like lightweight VMs, but the isolation guarantees are… situat...]]></description>
                        <content:encoded><![CDATA[Everyone's defaulting to containers (Docker, Podman) for isolating single agents. Feels like cargo-culting. We're treating them like lightweight VMs, but the isolation guarantees are… situational.

Systemd-nspawn gets dismissed as "for systemd nerds," but for a single static binary like an agent, it's worth comparing. No daemon, no JSON layers, no Dockerfile gymnastics.

**Key considerations:**

*   **Overhead**: `nspawn` boots a minimal OS image around your binary. A container *is* your binary (plus maybe a distroless base). Which is actually heavier? Depends.
*   **Artifact Integrity**: Both can use signed images/artifacts. With containers, you're trusting the registry and the hashes. With `nspawn`, you're often building the image locally from signed packages—different supply chain.
*   **Orchestration**: If you're already steeped in Kubernetes, containers win. If you're on bare metal and already use systemd for everything else… `nspawn` integrates cleanly.

Example `nspawn` unit file snippet:
```ini

Boot=no
Ephemeral=yes
PrivateUsers=yes
CapabilityBoundSet=~CAP_SYS_ADMIN CAP_NET_RAW
```

The real question: are we adding a container runtime because we need isolation, or because it's the trendy abstraction? For a single agent, `nspawn` can be simpler and more transparent. Prove me wrong.

mj]]></content:encoded>
						                            <category domain="https://openclawsecurity.net/community/openclaw-container-hardening/">Container and Runtime Hardening</category>                        <dc:creator>Maya Johansson</dc:creator>
                        <guid isPermaLink="true">https://openclawsecurity.net/community/openclaw-container-hardening/comparison-container-vs-systemd-nspawn-for-single-agent-isolation/</guid>
                    </item>
				                    <item>
                        <title>Check out this minimal OCI bundle config for runc.</title>
                        <link>https://openclawsecurity.net/community/openclaw-container-hardening/check-out-this-minimal-oci-bundle-config-for-runc/</link>
                        <pubDate>Sat, 04 Jul 2026 09:00:00 +0000</pubDate>
                        <description><![CDATA[Hey everyone! I&#039;ve been experimenting with running my OpenClaw agent in a minimal runc container. I wanted to share the OCI runtime config I landed on after a lot of reading. It&#039;s focused on...]]></description>
                        <content:encoded><![CDATA[Hey everyone! I've been experimenting with running my OpenClaw agent in a minimal runc container. I wanted to share the OCI runtime config I landed on after a lot of reading. It's focused on being as locked down as possible while still letting a Python-based agent function.

The goal was a rootless container with a read-only rootfs and minimal capabilities. I dropped everything except `CAP_DAC_OVERRIDE` (so my agent can still read its own config files) and `CAP_NET_BIND_SERVICE` since it needs a specific port. I also set the `no-new-privileges` security flag. Here's the core part of the `config.json`:

```json
"process": {
    "user": {
        "uid": 1000,
        "gid": 1000
    },
    "capabilities": {
        "bounding": ,
        "effective": ,
        "permitted": 
    },
    "noNewPrivileges": true
},
"root": {
    "path": "rootfs",
    "readonly": true
},
```

I'm still pretty new to this low-level container stuff. Does this look sane for a security-sensitive agent? Have I missed any obvious hardening steps? Would love a step-by-step guide on adding a seccomp profile next!

Thanks!]]></content:encoded>
						                            <category domain="https://openclawsecurity.net/community/openclaw-container-hardening/">Container and Runtime Hardening</category>                        <dc:creator>Priya Sharma</dc:creator>
                        <guid isPermaLink="true">https://openclawsecurity.net/community/openclaw-container-hardening/check-out-this-minimal-oci-bundle-config-for-runc/</guid>
                    </item>
				                    <item>
                        <title>Hot take: Read-only filesystems break too many agent features to be useful.</title>
                        <link>https://openclawsecurity.net/community/openclaw-container-hardening/hot-take-read-only-filesystems-break-too-many-agent-features-to-be-useful/</link>
                        <pubDate>Fri, 03 Jul 2026 19:01:00 +0000</pubDate>
                        <description><![CDATA[Hi everyone. I’m new here and still figuring things out, so please be gentle.

I’ve been trying to lock down my agent’s container by making the filesystem read-only. It seems like the first ...]]></description>
                        <content:encoded><![CDATA[Hi everyone. I’m new here and still figuring things out, so please be gentle.

I’ve been trying to lock down my agent’s container by making the filesystem read-only. It seems like the first security step everyone recommends. But every time I do, something basic breaks—either the agent can’t write logs, update a simple sqlite cache, or even download a tool it needs to function.

Am I missing something? It feels like you either have a secure, read-only setup with a broken agent, or a working agent with a wide-open filesystem. Has anyone actually gotten a complex agent to work well with a fully read-only root? I’d love some practical guidance.]]></content:encoded>
						                            <category domain="https://openclawsecurity.net/community/openclaw-container-hardening/">Container and Runtime Hardening</category>                        <dc:creator>Carla R.</dc:creator>
                        <guid isPermaLink="true">https://openclawsecurity.net/community/openclaw-container-hardening/hot-take-read-only-filesystems-break-too-many-agent-features-to-be-useful/</guid>
                    </item>
							        </channel>
        </rss>
		