On Thu, Sep 27, 2018 at 5:11 PM Tycho Andersen <tycho@xxxxxxxx> wrote: > > As an alternative to SECCOMP_FILTER_FLAG_GET_LISTENER, perhaps a ptrace() > version which can acquire filters is useful. There are at least two reasons > this is preferable, even though it uses ptrace: > > 1. You can control tasks that aren't cooperating with you > 2. You can control tasks whose filters block sendmsg() and socket(); if the > task installs a filter which blocks these calls, there's no way with > SECCOMP_FILTER_FLAG_GET_LISTENER to get the fd out to the privileged task. [...] > diff --git a/kernel/ptrace.c b/kernel/ptrace.c > index 21fec73d45d4..289960ac181b 100644 > --- a/kernel/ptrace.c > +++ b/kernel/ptrace.c > @@ -1096,6 +1096,10 @@ int ptrace_request(struct task_struct *child, long request, > ret = seccomp_get_metadata(child, addr, datavp); > break; > > + case PTRACE_SECCOMP_NEW_LISTENER: > + ret = seccomp_new_listener(child, addr); > + break; Actually, could you amend this to also ensure that `data == 0` and return -EINVAL otherwise? Then if we want to abuse `data` for passing flags in the future, we don't have to worry about what happens if someone passes in garbage as `data`.
