Re: [PATCH v6 3/5] seccomp: add a way to get a listener fd from ptrace
From: Tycho Andersen
Date: Wed Oct 17 2018 - 11:00:28 EST
On Wed, Oct 17, 2018 at 07:25:00AM +0000, Michael Tirado wrote:
> On Thu, Sep 13, 2018 at 12:02 AM Andy Lutomirski <luto@xxxxxxxxxxxxxx> wrote:
> > Or we could have a
> > seccomp() mode that adds a filter but only kicks in after execve().
> > --Andy
> Hey that's a pretty good idea, then we could block execve in a seccomp
> launcher without post-exec cooperation, or that patch I wrote that used
> an execve counter which probably should have been through prctl instead.
> As for the rest of this long thread,
> has anyone mentioned a specific use case that I missed? I didn't see code
> patches sent to the linux-kernel mailing list, only this discussion thread
> so I'm probably missing some important context. Was it for loading modules
> into kernel from a container? Couldn't that be handled completely in user
> space without using seccomp at all? Do we really want to turn seccomp into
> a container IPC mechanism? It seems out of scope IMO, and especially
> if it could be handled in user space already.
That's one of the use cases, but there are a large number of others. I
discuss a few in patch 1:
> Why does it have to be a file descriptor, what would you be writing back to?
> Could waitid be used somehow instead of ptrace to get notification
> from a filter?
You can already do this with SECCOMP_RET_TRACE. Of course, that means
the task has to be traced, and avoiding that is the point of this
> tldr, can someone kindly tell me how to find all the details surrounding these
> patches so I can stop making really bad guesses?
FWIW, I'm dropping the ptrace bits (and the fd passing bits) from the
next version, because they seem fairly controversial. So this will be