I don't think it's necessary to revert. The default profile allows everything that you can do with io_uring -- and custom profiles should be modified accordingly. I was more just surprised that this wasn't mentioned at the time. io_uring will grow support for more syscalls in the future so we should keep an eye on this.

I agree with cyphar. The topics were more about the ability to configure the filter for uring syscalls, not that it really created any security issue yet, especially not for the default config.

we are in the process of discussing enabling io_uring for the Podman seccomp profile and I was kind of surprised this was enabled in the default configuration for Moby.

From the discussion we had (containers/common#1264), we believe that enabling it is not future-proof as we have no control over what syscalls might be enabled in io_uring in the future. On the other end, it would be nice if there are no such differences between Podman and Moby.

It is just a theoretical question at this point but how this would be future-proof as we have no control over the syscalls that will be added in the future to io_uring and could potentially be a problem when the current configuration is used on a future kernel? This differs from the model we are using for seccomp right now, that new syscalls default to ENOSYS and we cherry-pick the safe ones to enable.

On the other hand, if any syscall adds a feature that opens a potential security issue (openat(O_GIVEMEROOT) for instance 😉), we would need to react to it in the same way -- releasing a new version of Docker which disallows that flag. Though in the case of io_uring, we cannot use seccomp to restrict the bits of kernel VFS it hits during execution.

I spoke to Jens Axboe at LPC and he said that in general they would be open to having a more capable restriction mechanism for io_uring (but for obvious reasons we cannot use seccomp for this) so this might be improved in the future.

(As an aside, If we do have to block io_uring-related syscalls we need to make them return -ENOSYS.)

io_uring is a special one though, potentially every other syscall could be multiplexed by io_uring at some point, while the likelihood of a flag that changes completely the meaning of a syscall sounds less likely; or at least I hope the security implications of something like openat(O_GIVEMEROOT) would be considered during the review :-)

I wonder why the syscalls called by io_uring couldn't go through the same checks as the syscalls that are called directly so that the same seccomp profile could still work with io_uring without any change.

for future visitors; these were removed again in;

• seccomp: block io_uring_* syscalls in default profile #46762
• and in containerd: Update RuntimeDefault seccomp profile to disallow io_uring related syscalls containerd/containerd#9320