Container and Runtime Hardening - openclawsecurity.net Forum

Switched from Docker to rootless Podman, here is why

Ash P. — Mon, 29 Jun 2026 11:00:07 +0000

Hey everyone, I’ve been running OpenClaw agents in Docker on my home server for a few months. I kept reading about rootless containers being a big deal for security, so I decided to take the plunge and switch to Podman. It was a bit of a weekend project, but I wanted to share my experience and reasoning. My main goal was to reduce the attack surface. In Docker, the daemon runs as root, and if something breaks out of the container, it could have root on my host. That scared me a bit, especially as I’m trying to learn more about securing my AI agents. Podman runs containers as my regular user by default, which felt like a safer starting point. The setup wasn’t too bad. I installed Podman on my Ubuntu server, migrated my Docker Compose setup for my agents using `podman-compose`. The biggest “aha” moment was realizing I didn’t have to mess with a daemon anymore. I can just start containers with my user, and it uses my user’s namespace. It feels more lightweight. I’m still learning, so I have some questions. Are there any specific Podman features or security flags I should be combining with this rootless mode for my OpenClaw agents? Like, should I always run with `--read-only` or drop all capabilities by default? Also, any gotchas with networking or volume mounts in rootless mode that I should watch out for? Overall, it feels like a step in the right direction for my little home lab. The peace of mind is worth the slight learning curve. Ash

What's the current best practice for mounting models read-only?

Marta Reyes — Mon, 29 Jun 2026 02:00:28 +0000

Hey everyone! 👋 I've been diving deep into my OpenClaw deployment this week, trying to tighten up the security posture of my agent containers. One thing that keeps coming up in my reading is the principle of making filesystems read-only wherever possible to limit the blast radius if something gets compromised. My specific question is about the large language model files themselves—the `.gguf`, `.safetensors`, or `.bin` files we mount into containers for Ollama, TextGen WebUI, or similar. These are massive, static assets that the container should never need to write to. I *think* the goal is to mount them with a read-only bind mount, but I'm getting a bit tangled in the specifics across different orchestration tools. Here’s my current approach with Docker Compose for an Ollama service, but I'd love to know if this is optimal or if I'm missing something: ```yaml services: ollama: image: ollama/ollama:latest container_name: ollama restart: unless-stopped volumes: # For the model storage directory itself, I use a named volume for persistence - ollama_models:/root/.ollama/models # But then, for specific pre-pulled models, I was trying a bind mount like this: - type: bind source: /home/marta/models/llama3.1-8b.Q4_K_M.gguf target: /root/.ollama/models/llama3.1-8b.Q4_K_M.gguf read_only: true ``` My concerns and questions: * **Does this even work correctly?** Some applications might try to write metadata or a small sidecar file next to the model, and a strict read-only mount could break that. Has anyone seen issues with Ollama or other servers when the model file is mounted strictly `ro`? * **Is a bind mount the right tool, or should I be using a named volume with `ro` option?** I've seen both approaches. * **What about at the Docker run level?** The command would be something like: ```bash docker run -d -v /home/marta/models/llama3.1-8b.Q4_K_M.gguf:/root/.ollama/models/llama3.1-8b.Q4_K_M.gguf:ro ollama/ollama:latest ``` * **Kubernetes / K8s folks:** How do you handle this with a `PersistentVolumeClaim`? Is it just `readOnly: true` in the volume mount spec? * **Beyond the mount:** Should we also be combining this with a container runtime security profile, like `seccomp` or `apparmor`, to block write syscalls to that path as a second layer? Or is that overkill? I'm also thinking about scenarios where you might have a "model cache" volume that gets populated by a separate process (like a CLI pull), and then multiple read-only agent containers can attach to it. How would you structure that? Really eager to hear how others are locking this down. Share your config snippets and horror stories if a read-only mount broke something!

Walkthrough: Hardening the OpenClaw process with grsecurity/PaX flags

Marcus Chen — Sun, 28 Jun 2026 03:00:32 +0000

Everyone talks about hardening containers. They drop caps, set AppArmor, call it a day. It's theater. Real hardening starts at the kernel boundary with the process itself. OpenClaw's agent is a Go binary. Let's make the kernel treat it like a hostile entity. Grsecurity/PaX flags are the only way to get meaningful runtime prevention. Most distros have them stripped out. You need a custom kernel. If you're not running one, this post isn't for you. Here's the minimal set for the agent process. Apply via `paxctl` or `setfattr` on the binary *before* it runs. ``` # Set PaX flags sudo paxctl -c /path/to/openclaw-agent sudo paxctl -m /path/to/openclaw-agent sudo paxctl -PEMSRx /path/to/openclaw-agent ``` Breakdown of `-PEMSRx`: * `P` PaX Enable * `E` Emulate Trampolines * `M` Restrict mprotect * `S` SegvGuard * `R` Randustack * `x` Enforce MPROTECT This does a few key things: * Prevents W^X violations. Stops shellcode execution. * Randomizes stack. Hardens against ROP. * Restricts `mprotect`. Stops memory region trickery. Without this, a single memory corruption bug in the agent's parsing logic could lead to trivial code execution. With it, the exploit chain gets a lot more complicated. The deployment catch: you need to set these flags *inside* the container, on the mounted binary. Your Dockerfile or build system must handle it. A read-only rootfs helps. Show me the code.

Troubleshooting: Agent fails with 'Operation not permitted' after hardening

Nick R. — Sat, 27 Jun 2026 04:01:07 +0000

Hey everyone. I've been working on hardening the container environment for my OpenClaw agents, trying to follow the principle of least privilege as strictly as possible. I'm running them as a rootless Podman container, with a read-only root filesystem, dropped all capabilities, and added a restrictive seccomp profile. The problem is, the agent now consistently fails to start, logging a generic `'Operation not permitted'` error. If I run the container with `--privileged`, it works fine, which tells me my hardening is *working*—maybe a bit too well. 😅 I've narrowed it down to happening after dropping `ALL` capabilities. I've been incrementally adding them back to see the minimum needed, but I'm hitting a wall. Here's my current, failing container run command: ```bash podman run -d --name openclaw-agent --read-only --user 1000:1000 --cap-drop=ALL --security-opt seccomp=/etc/docker/seccomp/openclaw-restricted.json -v ./agent-config:/etc/openclaw:ro localhost/openclaw-agent:latest ``` The agent log just shows: ``` ERROR: unable to initialize agent: operation not permitted ``` My gut says it's either: 1. A specific capability the agent binary needs (maybe `CAP_DAC_OVERRIDE` or `CAP_SYS_ADMIN`?). 2. Something in my custom seccomp profile that's too aggressive. Has anyone else gone down this path with the OpenClaw agent? What was the minimal capability set you landed on for basic operation? I'm trying to avoid just adding back `CAP_NET_RAW` or `CAP_SYS_CHROOT` without understanding exactly why it's needed. I'd also be happy to share my seccomp profile for a second set of eyes. Cheers, Nick

ELI5: Control groups (cgroups) for limiting agent resource usage

Omar F. — Thu, 25 Jun 2026 15:38:21 +0000

Alright, so we've all configured memory and CPU limits in our container orchestrator manifests. But when the agent inside decides to get greedy, what's *actually* enforcing that limit? The orchestrator just asks the kernel. The kernel uses cgroups. Think of a cgroup as a transparent box you put a process (or a whole tree of processes) into. Once it's in the box, the box has rules: "You can only use this much RAM," "You can only use 30% of a single CPU core," "Your I/O bandwidth to this disk is capped." The process can't break the box. The kernel ensures it. Why should we, as paranoid security folks, care? Because resource exhaustion is still a denial-of-service vector. If an agent goes rogue—or more likely, has a bug—and starts memory-leaking or fork-bombing, it shouldn't take down the host or co-located agents. cgroups are your last line of containment *before* the kernel's OOM killer starts picking victims randomly. Here's the practical bit. You're probably using them indirectly. But if you were to do it manually on a Linux host for a PID, it looks like this: ```bash # Create a new cgroup for memory sudo mkdir /sys/fs/cgroup/memory/agent_limits # Set a max of 512MB echo "536870912" > /sys/fs/cgroup/memory/agent_limits/memory.limit_in_bytes # Move the agent's PID into the cgroup echo > /sys/fs/cgroup/memory/agent_limits/cgroup.procs ``` Now, if the agent tries to allocate more than 512MB, its `malloc()` will fail. It's contained. For our agent deployments, we need to ensure: * The orchestrator's cgroup driver is correctly configured (cgroups v2 is a lot saner, by the way). * Our resource limits aren't just suggestions; they're enforced via cgroups. * We consider secondary controllers like `cpu` for throttling and `pids` to prevent fork bombs. The attack chain? An adversary who compromises an agent could attempt to exhaust host resources to disrupt other workloads or hide their activity in the chaos. Proper cgroup limits turn a host-wide DoS into a localized, logged event. Are we all verifying that our runtime's cgroup configurations are as strict as our zero-trust policies say they should be? Or are we just hoping the defaults are good enough? ~Omar

Help: Container won't start after applying my custom seccomp filter

Emily R. — Thu, 25 Jun 2026 04:00:49 +0000

Hi everyone. I've been working on our pilot program's runtime hardening, specifically trying to lock down the container environment for our OpenClaw agents. Following the principle of least privilege, I built a custom seccomp profile to block syscalls that shouldn't be needed for our basic data processing agents. I started from the Docker default profile and removed a bunch of syscalls related to module loading, kernel module operations, and some of the more obscure IPC calls. My goal was a profile stricter than default but not as restrictive as `seccomp=unconfined` (which we want to avoid). However, now my container exits immediately on start with a vague "bad system call" message and exit code 1. Here's the relevant part of my Docker run command and the custom profile I'm trying to apply: ```json { "defaultAction": "SCMP_ACT_ERRNO", "architectures": , "syscalls": [ { "names": , "action": "SCMP_ACT_ALLOW" } ] } ``` The list in `names` is the Docker default allowed list, *minus* about 15 syscalls I identified as high-risk (like `init_module`, `finit_module`, `delete_module`, `kcmp`, `lookup_dcookie`). I'm running it with: ```bash docker run --security-opt seccomp=./custom-profile.json my-agent-image ``` My main question: what's the best way to debug this? The error output isn't telling me *which* syscall is being blocked that the runtime actually needs. Is there a standard toolchain or method you all use to trace syscalls during container init to see what I've accidentally over-blocked? I'm also wondering if certain base images (we're using `debian:bookworm-slim`) might need something unexpected during startup that I haven't accounted for. I'm leaning towards using `strace` on a normal container run to build an allow-list empirically, but wanted to check in here first to see if there's a more container-native approach or if I'm missing a known pitfall.

My results after scanning our Claw deployment with trivy - not great.

Alex Chen — Wed, 24 Jun 2026 13:00:16 +0000

Hey everyone. So, I was reading about container security basics and decided to run `trivy image` on our main OpenClaw deployment. I was hoping to see a clean report, but honestly, it's a bit overwhelming. The scan found a bunch of HIGH and CRITICAL severity CVEs in the base layers. A lot of them seem to be in the system libraries (like libcrypto and libssl). We're using the default container setup from the quickstart guide. I'm not sure how worried I should be, since the agents themselves are probably not using those vulnerable parts? But it still feels bad. I'm using Python for our custom tools, so I understand dependencies, but container layers are new to me. How do you all handle this? Do you rebuild with a more minimal base, or is there a way to drop capabilities or make the filesystem read-only to limit the blast radius if something *is* exploitable? I'm anxious about messing with the runtime and breaking the agents. Thanks!

TIL: You can use `nsenter` to debug a broken container from the host.

Jamie K. — Wed, 24 Jun 2026 12:01:08 +0000

Hey everyone, I was trying to debug a nano claw container that had stopped responding. I couldn't get a shell inside it the usual way—it was just stuck. I was about to just kill it and restart, but I remembered someone in another thread mentioning `nsenter`. So, I looked it up and gave it a shot. For anyone else who hasn't used it, `nsenter` lets you "enter" the namespaces of a running process (like a container) from the host. It was a lifesaver. Here's basically what I did. First, I found the PID of the container's main process using `docker inspect` (or `podman inspect`). Then, as root on the host, I ran something like: `nsenter -t -m -u -n -p` This got me a shell inside the container's namespaces for mount, UTS, network, and PID. I could then poke around, check logs, and see what was actually hung. My question for you all who harden containers: Does using `nsenter` like this from the host bypass the container's own security? Like, if I'm in the container's PID namespace from the outside, am I still constrained by the container's dropped capabilities or read-only filesystems? Or does having root on the host just let me see everything anyway? I'm trying to understand the boundary between host-level tools for debugging and the actual container isolation we're trying to set up. It's super useful, but it feels like a powerful escape hatch 😅. Is there a best practice for this, or is it just an accepted risk for debugging? Maybe using rootless containers changes this?

Just finished a deep dive on the agent's file I/O - here's the map.

Anna Lindberg — Wed, 24 Jun 2026 09:03:38 +0000

Following my recent analysis of the Nemo Claw prototype's operational patterns, I have constructed a detailed threat model focused specifically on its file I/O surface. The agent's necessity to read, write, and execute files across its supply chain and during task execution presents a significant attack vector for persistence, data exfiltration, and integrity subversion. This post outlines the identified I/O nodes and proposes corresponding containerization constraints to enforce a least-privilege execution environment. The agent's file operations can be categorized into three distinct phases, each with unique security requirements: * **Supply Chain Ingestion:** This phase involves fetching and unpacking agent code, dependencies, and tool definitions. The primary threats here are dependency confusion, typosquatting, and the execution of malicious code from a poisoned package during installation. The I/O is characterized by: * Read from network (package registries). * Write to a local library/package directory (e.g., `site-packages`, `node_modules`). * Potential execution of setup scripts. * **Task Execution:** The operational phase where the agent performs its designated function. Threats include arbitrary code execution, sensitive file access, and tampering with host system files. I/O patterns are highly variable but typically involve: * Read access to task-specific input data and configuration. * Write access to a designated scratch or output directory. * Read/execute access to the installed toolset and its own codebase. * Potential reads from a knowledge base or vector store location. * **State and Attestation:** This phase handles persistence of session state, logs, and the generation of integrity proofs. Threats are data leakage of sensitive state and tampering with attestation logs. I/O is directed to: * Append/write to log files and audit streams. * Read/write to a serialized state file or database. * Write of attestation documents (e.g., in-toto link files, signed events). To contain these threats, the runtime environment must enforce strict boundaries. A rootless container with a carefully crafted security profile is the minimum viable isolation layer. Below is a proposed OCI runtime specification skeleton that maps the model to technical controls. ```json { "ociVersion": "1.0.2", "process": { "user": { "uid": 1000, "gid": 1000 }, "capabilities": { "bounding": [], "effective": [], "inheritable": [], "permitted": [], "ambient": [] }, "noNewPrivileges": true }, "root": { "path": "rootfs", "readonly": true }, "mounts": [ { "destination": "/proc", "type": "proc", "options": }, { "destination": "/dev", "type": "tmpfs", "options": }, { "destination": "/tmp", "type": "tmpfs", "options": } ], "linux": { "readonlyPaths": , "maskedPaths": , "seccomp": { "defaultAction": "SCMP_ACT_ERRNO", "architectures": , "syscalls": [ { "names": , "action": "SCMP_ACT_ALLOW" } ] }, "namespaces": } } ``` Critical hardening measures derived from the model include: * A read-only root filesystem, with explicit `tmpfs` mounts for `/tmp`, `/run`, and `/dev`. * Bind mounts for specific, writable directories corresponding to the phases above: * `--volume ./agent_state:/state:rw` (State and Attestation phase) * `--volume ./task_io:/task:rw` (Task Execution output) * `--volume ./packages:/opt/packages:ro` (Supply Chain Ingestion, pre-loaded) * Dropping all Linux capabilities, rendering privilege escalation binaries like `sudo` or `su` inert. * A tailored seccomp profile that denies system calls like `mount`, `swapon`, `ioctl` (on certain fds), and `keyctl`. * User namespace remapping to a non-zero UID/GID, mitigating potential kernel vulnerabilities. The next step in this analysis is formal verification of the seccomp profile and mount configuration against a defined policy stating that the agent cannot write to its own code or to host system paths. I am exploring the use of TLA+ to model the allowable I/O state transitions. I welcome peer review on the threat model categories and the proposed runtime spec constraints, particularly regarding the balance between isolation and the practical needs of long-running, stateful agents. - A.L.

How do I drop ALL capabilities and still let it function?

Ray K. — Wed, 24 Jun 2026 08:00:48 +0000

I've been trying to lock down an agent runtime to the absolute bare minimum. The goal is a container where the process has zero Linux capabilities left after `docker run --cap-drop=ALL`. The theory is solid, but in practice, the agent (or any non-trivial process) usually chokes. Here's the baseline failure. You drop everything, and even a simple `apt-get update` inside the container (if you're building) or the agent's own startup scripts will fail because they lack `CAP_DAC_OVERRIDE`, `CAP_NET_BIND`, or others. My test run looked like this: ```Dockerfile FROM ubuntu:22.04 RUN apt-get update && apt-get install -y curl python3-minimal USER nobody ``` ```bash docker build -t test-cap . docker run --rm --user nobody --cap-drop=ALL test-cap python3 -c "import os; print('alive')" ``` This often works for a pure Python print, but try having the agent write to a log file in a mounted volume, or resolve a network host, and it will hit a wall. The core problem: Most hardening guides stop at dropping obvious caps like `NET_RAW`. I want to know what the actual **minimum set** is for a typical OpenClaw agent that needs to: * Write logs to a pre-mounted, writable directory (`/var/log/agent`). * Make outbound HTTP/HTTPS calls to a defined allowlist. * Fork subprocesses for tool use (e.g., running `nmap` or `whois`). From my testing, you can't run with truly zero caps if you use a non-root user and have any restrictive mount. You'll need to add back at least: * `CAP_DAC_OVERRIDE` (or fix all file/directory permissions perfectly) * `CAP_NET_BIND_SERVICE` (if binding to ports < 1024, but usually not needed for clients) * Maybe `CAP_SETPCAP`? (usually not) What's the community's experience? Has anyone successfully run an agent with `--cap-drop=ALL` and only added back one or two? What were they? --Ray