On Thu, Sep 6, 2018 at 8:28 AM, 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. Hmm. I contemplated this a bit and looked at your example a bit, and I have a few thoughts: - What happens if you nest code like your sample? That is, if you are already in some container that is seccomped and there's a listener, can you even run your sample? - Is there any association between the filter layer that uses the USER_NOTIF return and the listener? How would this API express such a relationship? I realize that my dream of how this should all work requires eBPF and BPF_CALL, so it may not be viable right now, but I'd like a better understanding of how this all fits together. Also, I think that it's not strictly true that a filter that blocks sendmsg() is problematic. You could clone a thread, call seccomp() in that thread, then get a listener, then execve(). Or we could have a seccomp() mode that adds a filter but only kicks in after execve(). The latter could be generally useful. --Andy
