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

[Dmitry V. Levin]

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.


-- 
ldv
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 801 bytes
Desc: not available
URL: <http://lists.strace.io/pipermail/strace-devel/attachments/20190923/aba650bd/attachment.bin>