Re: [PATCHSET RFC 0/2] Per-task io_uring opcode restrictions

[Gabriel Krisman Bertazi <krisman@suse.de>]

Jens Axboe <axboe@kernel.dk> writes:

> Hi,
>
> One common complaint is that io_uring doesn't work with seccomp. Which
> is true, as seccomp is entirely designed around a classic sync syscall -
> if you can filter what you need based on a syscall number and the
> arguments, then it's fine. But for anything else, it doesn't really
> work. This means that solutions that rely on syscall filtering, eg
> docker, there's really not much you can do with seccomp outside of
> entirely disabling io_uring. That's not ideal.
>
> As I do think that's a gap we have that needs closing, here's an RFC
> attempt at that. Suggestions more than welcome! I want to arrive at
> something that works for the various use cases.
>
> io_uring already has a filtering mechanism for opcodes, however it needs
> to be done after a ring has been created. The ring is created in a
> disabled state, and then restrictions are applied, and finally the ring
> is enabled so it can get used. This is cumbersome and doesn't
> necessarily fit everybody's needs.
>
> This patch adds support for extending that same list of disallowed
> opcodes and register to something that can be applied to the task as a
> whole. Once applied, any ring created under that task will have these
> restrictions applied. Patch 1 adds the basic support for this, and patch
> 2 adds support for having the restrictions applied at fork or thread
> create time too, so any task or thread created under the current task
> will get the same restrictions.

Hi Jens,

Considering this is like to seccomp, a security mechanism, I don't see a
use case for running without IORING_REG_RESTRICTIONS_INHERIT.  Otherwise
there is a quick way around it by just execve'ing into itself.  IIRC,
seccomp also doesn't support disabling filters for the same reason.
So, unless someone has a use case, I'd suggest dropping the flag
and just making IORING_REG_RESTRICTIONS_INHERIT the default behavior.

Beyond that, adding more restrictions on an already restricted
application would be a useful use-case, so returning -EBUSY on
current->io_uring_restrict might not be doable long trem.  But feature
can be added later.

Finally, I suspect we will come quickly to the need of more complex
filtering of arguments, like seccomp.  Again, something that can be
added later but could be considered now for the interface.

> A few test cases can be found in liburing, in the task-restrictions
> branch:
>
> https://git.kernel.org/pub/scm/linux/kernel/git/axboe/liburing.git/log/?h=task-restrictions
>
>  include/linux/io_uring.h       |  2 +-
>  include/linux/io_uring_types.h |  2 ++
>  include/linux/sched.h          |  1 +
>  include/uapi/linux/io_uring.h  | 16 ++++++++++++++
>  io_uring/io_uring.c            | 10 +++++++++
>  io_uring/register.c            | 39 ++++++++++++++++++++++++++++++++++
>  io_uring/tctx.c                | 23 ++++++++++++--------
>  kernel/fork.c                  |  6 ++++++
>  8 files changed, 89 insertions(+), 10 deletions(-)

-- 
Gabriel Krisman Bertazi