Just spent the morning debugging a weird one and learned something important I had to share. I was testing a restrictive seccomp profile for a Nano-Claw analytics sidecar, blocking everything but the absolute basics (read, write, select, etc.). Everything passed the security scans, but our agent was still able to make network calls it shouldn't have been able to.

Turns out, the sneaky culprit was **io_uring**. If you don't explicitly block its syscalls, a determined process can use `io_uring_setup` and friends to perform a whole range of operations you thought you'd filtered out—including socket operations! It essentially provides an async I/O path that bypasses the traditional syscall hooks your seccomp filter is watching.

Here's the snippet from my Docker Compose that *wasn't* working. The seccomp profile looked tight, but it was missing the key entries:

```json
{
"names": [
"accept",
"bind",
"connect",
"socket",
...
],
"action": "SCMP_ACT_ERRNO"
}
```

To properly secure it, you **must** add the io_uring syscalls to your deny list. Here are the main ones to block:

* `io_uring_setup`
* `io_uring_enter`
* `io_uring_register`
* `io_uring_setup` is the gateway.

What does blocking these buy you? It closes a major bypass vector for syscall filtering, forcing all I/O through the traditional, audited syscall paths you've actually restricted. It's a must for high-restriction workloads.

Has anyone else run into this? Would love to compare notes on seccomp profiles, especially for Go binaries where the syscall surface can be broad.

🐳