[GSoC][RFC]: seccomp-assisted syscall filtering

[Chen Jingpiao]

On 03/25 10:36, Dmitry V. Levin wrote:
> On Wed, Mar 21, 2018 at 10:17:08PM +0800, Chen Jingpiao wrote:
> > On 03/12 02:29, Eugene Syromiatnikov wrote:
> > > On Mon, Mar 12, 2018 at 10:38:37AM +0800, Chen Jingpiao wrote:
[...]
> It may be worth adding an option to explicitly enable/disable this
> seccomp-based filter while it's being developed.  When it's ready for
> non-experimental use, it will be enabled automatically depending on the
> kernel support and tracing options, but we might want to keep the option
> of disabling the feature explicitly.

Yes.

> 
> Please note the following important points of this project that
> I'd recommend to mention in the proposal:
> 
> - Runtime check for the seccomp semantics implemented by the kernel,
>   similar to the runtime check for PTRACE_SEIZE, with fallback to the
>   traditional filtering.

Yes, something like this [1]. I will do more research.

A demo:

bool
test_seccomp_filter(void)
{
#ifdef SECCOMP_MODE_FILTER
	if (prctl(PR_SET_SECCOMP, SECCOMP_MODE_FILTER, NULL, 0, 0) < 0) {
		debug_msg("SECCOMP_MODE_FILTER doesn't work: %s",
			  strerror(errno));
		return false;
	}
	return true;
#else
	debug_msg("SECCOMP_MODE_FILTER doesn't work: not define SECCOMP_MODE_FILTER");
	return false;
#endif
}

> - Optimization of the BPF code, for example, in some cases it's better
>   to list traced syscalls, in other cases - to list those syscalls that
>   are not traced.  Sometimes (e.g. -e trace=all) there is no point in
>   enabling a seccomp-based filter even if the kernel supports it.

I have concerned this problem, but I have not found a satisfying way to
deal with the problem.  One is count the numbers of traced syscall,
and compare with nsyscalls. Other is if number_set.not is set, we unable
seccomp filter (seems upcoming advanced filtering syntax delete the trace_set).

Second solution is not a good idea if use command:

$ strace -etrace=!%class[,/regex ...] PROG

$ grep -w TF linux/x86_64/syscallent.h | wc -l
60

Do you have any good suggestions? Thank you.

> 
> With regards to the proposed timeline, please note the following subtasks
> may take more time than expected:
> - Integrating with the upcoming advanced filtering syntax (one of last
>   year gsoc projects that is not merged yet but will hopefully be merged
>   soon).
> - Reviewing and merging to master.

Ok.

Thank you, I updated the proposal [2].

[1]: https://outflux.net/teach-seccomp/autodetect.html
[2]: https://gist.github.com/ppiao/4881da820b35c96075fa8d76bee073f3

--
Chen Jingpiao