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": ["SCMP_ARCH_X86_64"],
"syscalls": [
{
"names": [
"brk", "clock_gettime", "close", "exit", "exit_group",
"fstat", "futex", "getpid", "getrandom", "gettid",
"madvise", "mmap", "mprotect", "munmap", "nanosleep",
"openat", "pread64", "read", "readlink", "rseq",
"sched_yield", "write"
],
"action": "SCMP_ACT_ALLOW"
},
{
"names": [
"ioperm", "iopl", "mremap", "mbind", "set_mempolicy",
"get_mempolicy", "migrate_pages", "move_pages"
],
"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
Model the threats before the code.