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

[Paul Chaignon]

On Sun, Sep 22, 2019 at 12:40:06PM +0300, Dmitry V. Levin wrote:
> On Sun, Sep 22, 2019 at 11:32:09AM +0200, Paul Chaignon wrote:
> > On Sun, Sep 22, 2019 at 12:22:54PM +0300, Dmitry V. Levin wrote:
> > > On Sun, Sep 22, 2019 at 10:49:10AM +0200, Paul Chaignon wrote:
> > > > On Sat, Sep 21, 2019 at 07:57:21PM +0300, Dmitry V. Levin wrote:
> > > > > On Sat, Sep 21, 2019 at 07:02:24PM +0300, Dmitry V. Levin wrote:
> > > > > [...]
> > > > > > @@ -1759,6 +1768,11 @@ init(int argc, char *argv[])
> > > > > >  		error_msg_and_help("PROG [ARGS] must be specified with -D");
> > > > > >  	}
> > > > > >  
> > > > > > +	if (seccomp_filtering && !followfork) {
> > > > > > +		error_msg("-n implies -f");
> > > > > > +		followfork = 1;
> > > > > > +	}
> > > > > > +
> > > > > >  	if (optF) {
> > > > > >  		if (followfork) {
> > > > > >  			error_msg("deprecated option -F ignored");
> > > > > 
> > > > > Looks like -n is currently not compatible with -p, compare e.g.
> > > > > 
> > > > > ./set_ptracer_any ./sleep 1 & ../strace -n -f -qq -e trace=exit_group -p $!
> > > > > and
> > > > > ./set_ptracer_any ./sleep 1 & ../strace    -f -qq -e trace=exit_group -p $!
> > > > 
> > > > No, it's not.  As far as I know, there is currently no way to attach a
> > > > seccomp-bpf filter to a running process.  We'll need to add an error
> > > > message.
> > > 
> > > Could we just ignore -n for processes attached using -p?
> > 
> > Rigth, I forgot we can have both a command and -p.  Maybe a warning if -p
> > is given without a command (i.e., -n has no effect) and a debug message if
> > both -p and a command are given (i.e., -n only effective for the command
> > part)?
> 
> Yes, a warning in case when -n is disabled e.g. due to -p would be fine.
> 
> With the current patchset, when both -p and a command are given, the
> command is traced properly but processes attached using -p are not really
> traced, this has to be fixed.

The culprit is restart_op in dispatch_event.  It currently does not depend
on whether the traced process has a seccomp filter; we never want to
restart in PTRACE_CONT when we don't have a seccomp filter attached.

I'm going to send (today) an updated pachset that fixes this.  I've added
a seccomp_filter field in struct tcb to track whether a process has a
seccomp filter and be able to act accordingly.

Paul