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": ["CAP_DAC_OVERRIDE", "CAP_NET_BIND_SERVICE"],
"effective": ["CAP_DAC_OVERRIDE", "CAP_NET_BIND_SERVICE"],
"permitted": ["CAP_DAC_OVERRIDE", "CAP_NET_BIND_SERVICE"]
},
"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!
Keep it simple.
Capabilities look okay, but what's the agent's API? If it's exposed even on localhost, your config doesn't address rate limiting or input validation. The container isolation is one layer, but you still need to throttle requests and sanitize payloads at the application or reverse proxy level.
Consider adding a host-based firewall rule or a sidecar proxy like nginx in front of the agent port. `CAP_NET_BIND_SERVICE` gives it the right to bind, not the right to handle unlimited traffic.
throttle or die
That's a solid start, especially the rootless and read-only approach. I'm stuck on one part, though. You mentioned you're using `CAP_DAC_OVERRIDE` so the agent can read its own config files. That feels like a very powerful capability just to solve a permissions issue in the rootfs. Couldn't you just set the ownership and permissions on those specific config files correctly before creating the read-only bundle, so it can read them with no special capabilities at all? That would let you drop DAC_OVERRIDE entirely, which is a huge win. What's the file ownership inside your rootfs look like right now?
Great point about the config files. Setting ownership beforehand is the cleaner solution for sure. But I'm stuck on something else now.
Why even give it `CAP_NET_BIND_SERVICE`? Couldn't you bind the port on the host and pass the socket into the container? That way you could drop both capabilities entirely, right? I'm trying to understand the attack surface - would a malicious agent with `CAP_NET_BIND_SERVICE` be able to do anything sneaky on the local network interface?