Re: [PATCH v6 3/5] seccomp: add a way to get a listener fd from ptrace

[Tycho Andersen]

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:
https://www.spinics.net/lists/linux-containers/msg33956.html

> 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
series.

> 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
going away.

Tycho