Switched from OpenHands to OpenClaw after finding my assistant had unnecessary filesystem access. The OpenHands default profile allowed full read/write in the user's home directory, which is excessive for an agent that only needs to interact with a notes application and a calendar.
Here's my current OpenClaw agent configuration. Looking for a review, especially on the seccomp profile and capabilities.
```yaml
agent_name: "personal_assistant"
runtime: "containerd"
base_image: "debian:bookworm-slim"
capabilities:
- "CAP_NET_BIND_SERVICE"
- "CAP_DAC_READ_SEARCH"
seccomp_profile:
default_action: "SCMP_ACT_ERRNO"
syscalls:
- action: "SCMP_ACT_ALLOW"
names:
- "read"
- "write"
- "poll"
- "clock_gettime"
- "epoll_wait"
- "accept"
- "bind"
filesystem_access:
- path: "/home/user/.local/share/notes_app"
permissions: ["rw"]
- path: "/home/user/.config/calendar"
permissions: ["r"]
- path: "/tmp"
permissions: ["rw"]
network_access:
allowed_hosts:
- "api.calendar.example.com:443"
```
My main goals:
* Isolate the agent's credentials (API keys for the calendar service) from the rest of the user session.
* Prevent lateral movement if the agent process is somehow compromised.
* Allow only the bare minimum syscalls.
Specific questions:
* Is `CAP_DAC_READ_SEARCH` actually required if I'm explicitly allowing the filesystem paths above?
* The seccomp list is short. Are there other common, safe syscalls I'm missing that won't broaden the attack surface?
* Should I consider a separate, namespaced user ID instead of relying solely on the filesystem ACLs?
audit your config
Your seccomp profile is missing several essential syscalls for a basic containerized process. The current list will likely cause immediate failures. For example, you've allowed `accept` and `bind` but omitted `socket` and `listen`. You're also missing core calls like `close`, `fstat`, `mmap`, `mprotect`, `munmap`, `brk`, `clone`, and `execve`. A minimal functional baseline for a dynamically linked binary would be closer to the Docker default seccomp profile, stripped of high-risk calls.
Regarding capabilities, `CAP_DAC_READ_SEARCH` is likely too permissive for your stated goal of credential isolation. This capability allows bypassing read and execute permission checks on files and directories. If your agent only needs to read a specific config file, a bind mount with strict ownership is safer than granting this capability.
For credential isolation, consider using the `keyctl` syscall in your seccomp rules if the agent uses kernel keyrings, or better yet, inject API keys via a dedicated, memory-only filesystem mount that isn't persisted to the host's disk.
Good move isolating those API keys, that's the whole point! I noticed your filesystem_access list is still giving the agent write to your notes directory and /tmp. If the assistant only needs to read calendar config and maybe write to a specific socket or log, I'd lock that down even more.
Maybe create a dedicated directory, like `/var/run/openclaw/assistant/`, bind-mount only that, and drop `CAP_DAC_READ_SEARCH`. That capability lets it read *any* file on the filesystem if it finds a way to break out of the mount points, which defeats the isolation goal.
Also, your network ACL only allows that one calendar host, which is perfect. Did you consider outbound DNS? The agent might need to resolve that hostname.
--Al