from Hacker News

Io_uring and seccomp (2022)

by pncnmnp on 10/9/24, 2:42 PM with 24 comments

• by eqvinox on 10/11/24, 9:47 PM

  Using seccomp with a default-open filter is a terrible idea to begin with; it wasn't really designed for any of this. Seccomp in its most basic form didn't even have a filter list, it just allowed read() and write(). (And close() or something, don't quote me on the details, the point is it was a fixed list.) You're supposed to use it with a default-closed filter and fully enumerate what you need. (Yes, that's hard in a lot of cases, but still.)

  There have been other cases where syscalls got cloned, mostly to add new parameters, but either way seccomp with an "open" filter can only ever be defense-in-depth, not a critical line in itself.

  (Don't misunderstand, defense-in-depth is good, and keep using seccomp for it. But an open seccomp filter MUST be considered bypassable.)

• by deathanatos on 10/11/24, 8:32 PM

  This seems like an instance of an anti-pattern I've seen, which is inflating "permission" and "API call" to the same thing.

  IIRC, AWS does this, where permission is by API call. As an example, you can have permission to call ssm:GetParameter n times, but if you try to combine those n API calls into a batch with GetParameters, that's a different IAM perm, even though exactly the same thing is occurring.

• by cpuguy83 on 10/11/24, 8:34 PM

  Both Docker and containerd have started to block io_uring in the default profile for about a year now due to too many security issues with it.

• by theamk on 10/12/24, 3:53 AM

  I was thinking about how one would change io_uring design to be compatible with seccomp, and came up with a very simple one:

  A new io_uring fd comes with all operations disabled by default. User has to call "io_uring_register(fd, ENABLE_OP, op)" before operation is used for the first time. Then seccomp filter can easily filter enable_op calls to prohibit certain operations.

  It could even be added now in backward-compatible way - add a new feature to io_uring_setup that enables it. Then one could set seccomp filter to only accept setup requests with this feature set, and deny all others. Together, this should allow cooperating programs to pass seccomp filter, while programs that won't register ops could not use seccomp at all.

• by FridgeSeal on 10/12/24, 12:29 AM

  Surely this is a seccomp shortcoming, or kernel auth shortcoming, rather than an io_uring problem?

  That is, seccomp is (apparently? I’ve never used it myself) capable of intercepting direct calls. Obviously, that design isn’t going to be able to handle “indirect” calls in its default implementation.

  Either seccomp needs a way to act on the buffer or intercept io_uring calls, or there’s a need for a new auth mechanism that’s capable of handling io_uring style API’s.

  Torpedoing the whole api (a la gcp) feels like throwing the baby out with the bath water.

• by leni536 on 10/11/24, 7:06 PM

  > But if you've got a separation of duties where a sysadmin sets up seccomp filtering generically across applications

  Is this even possible, regardless of io_uring?

• by 0x74696d on 10/12/24, 1:49 AM

  Author here! The motivating example of this post is frankly pretty lousy in retrospect (and was even so soon after writing, given the friendly reminder from Giovanni Campagna that `socket` wasn't one of the io_uring opcodes). At best this is an interesting limitation of seccomp. Maybe relevant if you were using gVisor?