LWN: Comments on "Operations restrictions for io_uring"

Operations restrictions for io_uring

stefanha — Fri, 17 Jul 2020 08:02:24 +0000

This is more like seccomp for io_uring (a single syscall interface that multiplexes many other syscalls). Restrictions are finer-grained than what running a separate process with different credentials achieves.

Operations restrictions for io_uring

rwmj — Thu, 16 Jul 2020 17:48:29 +0000

I think the thing I was missing is the guest and the hypervisor, if it's like qemu, are in fact the same process so they have the same set of file descriptors. Thanks.

Operations restrictions for io_uring

corbet — Thu, 16 Jul 2020 17:22:09 +0000

First of all, just being able to access the other file descriptors the hypervisor has open would be a hole in its own right. The hypervisor surely doesn't want to share all of its open files with the client.

Beyond that, io_uring supports operations like openat2(), which will again use the credentials of the hypervisor.

Operations restrictions for io_uring

rwmj — Thu, 16 Jul 2020 17:13:25 +0000

giving such a ring to a client would open the door to actions like accessing other file descriptors opened by the hypervisor or opening new files with the hypervisor's credentials

I'm a bit confused on this point. It seems io_uring operations each include a file descriptor, so surely no matter how the uring was set up they can still only access file descriptors which the process has open (ie. ones passed in, or ones the process is able to open itself).

Operations restrictions for io_uring

clugstj — Wed, 15 Jul 2020 12:34:12 +0000

"using the credentials of the process that created the ring"

Instead of all this, why not provide a way to transfer ownership of the ring - then all the usual checks would work, right?

Operations restrictions for io_uring

flussence — Wed, 15 Jul 2020 11:39:58 +0000

It may be a bit late for the yearly predictions, but I think once sharp edges like these are fixed in io_uring there's going to be an inflection point where post-libc languages flock to it en masse. It has the same “shape” as things like the OpenGL fixed-function to shaders transition, and when I think about it that way it's weird that it came as late as it did. Linux's async story has historically been a bit dire.

Operations restrictions for io_uring

onlyben — Wed, 15 Jul 2020 06:36:19 +0000

Thanks cyphar, good to know. I imagine disabling io_uring (whether in a container or not) is not preferable due to its overall utility, however I imagine the patch mentioned in the article will be useful in cases like this and especially so if io_uring trends toward becoming more generic.

Operations restrictions for io_uring

cyphar — Wed, 15 Jul 2020 06:25:17 +0000

That link is out-dated and it's written as though the Docker seccomp configuration is a denylist rather than an allowlist -- it's the latter (anything else would be insecure). The correct source to use would be the source code for the default profile -- but it does turn out that they enabled support for io_uring last year and there wasn't much discussion on whether this would cause issues in the future.

However, io_uring only allows certain syscall-like operations to be done through it and they are all also permitted in the default seccomp profile (in both Docker and LXD) so there really isn't a change in security policy. However as io_uring gains more features we may have to revisit this.

Operations restrictions for io_uring

onlyben — Wed, 15 Jul 2020 05:12:59 +0000

Interesting, thanks for the response.

I noticed that Docker's default seccomp profile (https://docs.docker.com/engine/security/seccomp/) doesn't prevent io_uring inside containers. Looks like most of the syscalls it prevents are already gated by capabilities, but it'd be interesting to see if you could circumvent anything with io_uring.

Operations restrictions for io_uring

josh — Wed, 15 Jul 2020 03:38:56 +0000

Only if the seccomp filters allowed the use of the io_uring syscalls.

Operations restrictions for io_uring

onlyben — Wed, 15 Jul 2020 03:09:26 +0000

Interesting that seccomp() filters do not apply in io_uring. Does this mean that a process restricted under seccomp() could potentially execute prohibited system calls via io_uring?