Re: [Ksummit-discuss] [TECH TOPIC] seccomp

[Andy Lutomirski <luto@kernel.org>]

On Fri, Jul 19, 2019 at 2:35 AM Christian Brauner <christian@brauner.io> wrote:
>
> In light of all this, I would argue that we should seriously look into
> extending seccomp to allow filtering on pointer arguments.

I won't be at LPC this year, but I was thinking about this anyway.  I
have the following suggestion that might be a bit unorthodox: have
syscalls opt into this filtering.  Specifically, a syscall that
supports pointer filtering would be refactored the way a bunch of our
syscalls are already refactored.  The baseline situation is:

SYSCALL_DEFINE1(syscallname, struct foo __user *, buf) { ... }

Instead, we would do:

SYSCALL_FILTERABLE(syscallname, struct foo __user *, buf)
{
  int ret;
  struct foo kbuf;
  ret = copy_from_user(&kbuf, buf, sizeof(buf));
  if (ret)
    return ret;

  ret = seccomp_deep_filter(syscallname, 0, &kbuf);
  if (ret)
    return ret;

  return do_syscallname(&kbuf);
}

In principle, if we know we're doing a FILTERABLE syscall, we could
skip the initial seccomp invocation and just defer it until
seccomp_deep_filter(), although this might interact badly with any
SECCOMP_RET_PTRACE handles that change nr.

To make this robust, it might help a lot if the generation of these
stubs was mostly automated.