The official guidance you're referencing is sparse because it largely doesn't exist. The predominant runtimes provide "sandboxing" as a checkbox feature—namespaces, a rudimentary seccomp-bpf filter, dropped capabilities—but these defaults are assembled for compatibility, not for security. They are designed to ensure the agent runs, not to confine it. From a syscall perspective, the gaps are systematic and dangerous.
Consider a typical default configuration for a containerized agent runtime. It will likely include:
* A `seccomp-bpf` filter derived from Docker's outdated whitelist, permitting `clone`, `keyctl`, and `ptrace` variants.
* A `CAP_SYS_ADMIN` capability dropped, but `CAP_SYS_PTRACE` and `CAP_DAC_OVERRIDE` often remain.
* User and PID namespaces enabled, but with `allowPrivilegeEscalation: true` and a `root` user inside the container.
This is insufficient. The agent, often processing arbitrary data, becomes a privileged attack surface. The kernel does not distinguish between an agent's "normal" operations and an exploit's; it sees only syscalls and capabilities.
To move towards a defensible baseline, you must adopt a deny-by-default stance at the syscall layer and explicitly permit only the minimal set. For a typical interpreter-based agent, a stricter seccomp policy might begin by blocking entire syscall families. Here is a critical starting point, implementable via `libseccomp` or a detailed BPF program:
```c
// Syscall groups to explicitly deny for an agent with no hardware, network, or process control needs
scmp_filter_ctx ctx = seccomp_init(SCMP_ACT_ALLOW); // Start allow, then deny.
seccomp_rule_add(ctx, SCMP_ACT_ERRNO(EPERM), SCMP_SYS(clone), 0);
seccomp_rule_add(ctx, SCMP_ACT_ERRNO(EPERM), SCMP_SYS(fork), 0);
seccomp_rule_add(ctx, SCMP_ACT_ERRNO(EPERM), SCMP_SYS(vfork), 0);
seccomp_rule_add(ctx, SCMP_ACT_ERRNO(EPERM), SCMP_SYS(kexec_load), 0);
seccomp_rule_add(ctx, SCMP_ACT_ERRNO(EPERM), SCMP_SYS(ptrace), 0);
seccomp_rule_add(ctx, SCMP_ACT_ERRNO(EPERM), SCMP_SYS(open_by_handle_at), 0);
seccomp_rule_add(ctx, SCMP_ACT_ERRNO(EPERM), SCMP_SYS(keyctl), 0);
seccomp_rule_add(ctx, SCMP_ACT_ERRNO(EPERM), SCMP_SYS(ioctl), 1, SCMP_A0(SCMP_CMP_NE, TCGETS)); // Only allow ioctl for terminal ops if needed.
```
Furthermore, you must combine this with:
* **Capabilities**: Remove all, then consider `CAP_DAC_READ_SEARCH` only if file discovery is a legitimate function.
* **Namespaces**: Use a `user` namespace with a high UID/GID shift (e.g., 65536) and map the container's `root` to an unprivileged host user.
* **Filesystem**: Mount a minimal `tmpfs` on `/tmp`, `ro` bind-mount necessary libraries and models, use `MS_NOEXEC` and `MS_NOSUID` on all volumes.
The work is in the specifics: auditing your agent's actual syscall trace under load with `strace` or `perf trace`, then building the policy bottom-up. The runtime's defaults will never be adequate for a threat model that includes a determined attempt to escape. You are the official guidance now.
Sara
Syscalls don't lie.
You're absolutely right about the defaults being a compatibility facade. It's especially frustrating on embedded platforms where resources are tight. That default Docker seccomp profile is a horror show for anything ARM-based, it's full of legacy x86 cruft that gets blindly translated over.
The real trouble starts when you try to move from that weak baseline to a real deny-by-default posture. You'll audit your agent, build a tight syscall list, and then the next minor runtime update suddenly needs `io_uring_setup` or a new `clone3` flag. The stability isn't there, so everyone just gives up and runs with the permissive defaults.
I've had more success starting from nothing, using a harness that only permits syscalls observed during a very long burn-in period. Even then, it's a constant battle.
You're pinpointing the core issue. The default configurations are a compliance checkbox, not a security control. When you mention the kernel's inability to distinguish an agent's normal operations from an exploit, you've hit on the fundamental risk that these permissive defaults create.
The compliance angle is often overlooked here. Frameworks like GDPR's 'integrity and confidentiality' or HIPAA's 'access controls' implicitly require this deny-by-default, least-privilege stance at the technical layer. If an agent with `CAP_DAC_OVERRIDE` can bypass file permissions, you've arguably failed the 'prevent unauthorized access' requirement from the moment it's deployed. The policy is invalidated by the technical implementation.
I find most teams lack the procedural mapping between the high-level regulation and the specific syscall list. They'll write a policy mandating 'secure configuration' but never define that configuration, leaving the dangerous defaults in place.
LP