3 ms·

So, to my knowledge io_uring is a complete seccomp bypass (for all functionality it implements). Docker allows io_uring because "so far it isn't that big of a d

So, to my knowledge io_uring is a complete seccomp bypass (for all functionality it implements). Docker allows io_uring because "so far it isn't that big of a deal" (paraphrasing from Github issue 2 years ago). Given that io_uring now provides file IO and process execution... isn't it about time that someone starts thinking about the security implications? Are we going to just have a universal seccomp bypass for anyone who uses io_uring? How're the audit hooks coming along? Or LSM hooks? edit: K I've reached my HN rate limit again, thanks Dang. Anyway, here's a source for the Docker seccomp filter since someone replied inquiring. https://github.com/thaJeztah/docker/blob/master/profiles/seccomp/default.json https://github.com/thaJeztah/docker/blob/master/profiles/sec...

rotifer 4y ago
I don't follow it particularly closely, but I recall that there was a recent LWN article, "Security requirements for new kernel features" [1], which discussed the issue. [1] https://lwn.net/Articles/902466/ https://lwn.net/Articles/902466/
- staticassertion 4y ago
  Yeah, but the discussion hasn't gone anywhere lol the conclusion of the article is basically "yeah I guess they don't care"
the8472 4y ago
seccomp filters generally are whitelists. If they haven't whitelisted io_uring_setup it's a non-issue. They only suffer the performance consequences of userspace having to use the synchronous syscalls. also, iouring doesn't allow arbitrary syscalls. so it's not really a complete seccomp bypass even when allowed
- ori_b 4y ago
  > They only suffer the performance consequences of userspace having to use the synchronous syscalls. And the need to implement all the functionality twice. Who is going to do that?
  - the8472 4y ago
    Everyone who doesn't tightly control the systems they deploy to. io_uring is a new and developing interface so to support extant systems running libraries need to have fallback codepaths. Or more likely: they already have existing codepaths for the previous interfaces and add io_uring as a faster alternative.

rotifer 4y ago

I don't follow it particularly closely, but I recall that there was a recent LWN article, "Security requirements for new kernel features" [1], which discussed the issue. [1] https://lwn.net/Articles/902466/ https://lwn.net/Articles/902466/

staticassertion 4y ago
Yeah, but the discussion hasn't gone anywhere lol the conclusion of the article is basically "yeah I guess they don't care"

the8472 4y ago

seccomp filters generally are whitelists. If they haven't whitelisted io_uring_setup it's a non-issue. They only suffer the performance consequences of userspace having to use the synchronous syscalls. also, iouring doesn't allow arbitrary syscalls. so it's not really a complete seccomp bypass even when allowed

ori_b 4y ago
> They only suffer the performance consequences of userspace having to use the synchronous syscalls. And the need to implement all the functionality twice. Who is going to do that?
- the8472 4y ago
  Everyone who doesn't tightly control the systems they deploy to. io_uring is a new and developing interface so to support extant systems running libraries need to have fallback codepaths. Or more likely: they already have existing codepaths for the previous interfaces and add io_uring as a faster alternative.