[Ksummit-discuss] [TECH TOPIC] seccomp
Andy Lutomirski
luto at kernel.org
Fri Jul 19 12:32:59 UTC 2019
On Fri, Jul 19, 2019 at 2:35 AM Christian Brauner <christian at 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.
More information about the Ksummit-discuss
mailing list