On Thu, Sep 27, 2018 at 07:35:06PM +0200, Jann Horn wrote: > 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`. Yes, good idea. Thanks! Tycho
