[PATCH v6 1/3] Introduce seccomp-assisted syscall filtering

[Paul Chaignon]

On Mon, Sep 23, 2019 at 12:30:03PM +0300, Dmitry V. Levin wrote:
> On Mon, Sep 23, 2019 at 10:13:53AM +0200, Paul Chaignon wrote:
> > On Mon, Sep 23, 2019 at 12:00:54AM +0300, Dmitry V. Levin wrote:
> > > On Sun, Sep 22, 2019 at 10:13:29PM +0200, Paul Chaignon wrote:
> > 
> > [...]
> > 
> > > > +void
> > > > +init_seccomp_filter(void)
> > > > +{
> > > > +	struct sock_filter filter[BPF_MAXINSNS];
> > > > +	unsigned short len;
> > > > +
> > > > +	len = init_sock_filter(filter);
> > > > +
> > > > +	struct sock_fprog prog = {
> > > > +		.len = len,
> > > > +		.filter = filter
> > > > +	};
> > > > +
> > > > +	if (prctl(PR_SET_NO_NEW_PRIVS, 1, 0, 0, 0) < 0)
> > > > +		perror_func_msg_and_die("prctl(PR_SET_NO_NEW_PRIVS)");
> > > > +
> > > > +	if (prctl(PR_SET_SECCOMP, SECCOMP_MODE_FILTER, &prog) < 0)
> > > > +		perror_func_msg_and_die("prctl(PR_SET_SECCOMP, SECCOMP_MODE_FILTER)");
> > > > +}
> > > 
> > > I'm not sure we really want to terminate strace in this case.
> > 
> > If we don't, we will end up marking this process has having a seccomp
> > filter in startup_child() and we will miss events (because we'll restart
> > in PTRACE_CONT instead of PTRACE_SYSCALL).  One alternative could be to
> > drop the change in startup_child() (i.e., not set the seccomp_filter flag)
> > and always rely on the first seccomp-stop to detect whether a process has
> > a filter seccomp attached.
> 
> I'd rather rely on the first seccomp-stop if there are no drawbacks.

The only drawback I see is that we will have one additional stop if
seccomp-stops happen after syscall-entry-stops (Linux 4.8+).

Paul