[PATCH RFC 0/4] Seccomp-assisted syscall filtering

[Paul Chaignon]

On Sat, Jul 13, 2019 at 03:10:51PM +0300, Dmitry V. Levin wrote:
> On Sat, Jul 13, 2019 at 12:22:01PM +0200, Paul Chaignon wrote:
> > This patchset introduces syscall filtering in the kernel using
> > seccomp-bpf.  The first patch exports the trace_set set required to build
> > the BPF filtering program.  The second patch implements the main logic to
> > reduce the number of tracer stops.  The third let's strace skip the
> > seccomp-bpf setup when there aren't any syscalls to filter.  The last
> > patch adds tests.
> > 
> > Seccomp filtering is only enabled with the -n option.  The BPF program
> > implements a simple linear match of syscalls which can be improved in the
> > future without impacting user-observable behavior.
> > 
> > I am sending this as an RFC for several reasons.  First, I'd like to bring
> > attention to several design decisions:
> >   - When using the -n option, the state (enabled/disabled) of seccomp
> >     filtering is printed at startup.  Is that okay?
> 
> I think we should print this state if debugging is enabled, and
> issue a warning if seccomp filtering is requested but not available.

Sure, that's less verbose than current behavior.

> 
> >   - -n currently required -f.  Should -n imply -f instead?
> 
> I think -n should imply -f, but if -n was specified without -f,
> a warning should be issued.

Ok, that works.

> 
> > Second, I would like to add more tests for the BPF program, but I am not
> > quite sure how to proceed.  In particular, I would like to add a test with
> > a large (largest?) number of filtered syscalls.
> 
> What's the problem? You can filter as many syscalls as you like.

Ideally I'd like to have a test with one syscall on two, to stress the BPF
program's size.  Hardcoding such a set of syscalls in the tests in not a
good idea...  Is there a way to do that programmatically?  Would I have to
parse the syscallent.h files from the Shell scripts?

Paul