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

[Paul Chaignon]

On Sat, Jul 13, 2019 at 12:22:00PM +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?
>   - -n currently required -f.  Should -n imply -f instead?
> 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.

One thing I forgot: if the long term goal is to have seccomp filtering
enabled by default, we may want to be careful with the -n option.  We will
likely want an option to disable seccomp filtering when that time comes.
Changing the behavior of -n to "disable seccomp filtering" is probably not
a good idea, so maybe -n should take a value {enable,disable}, with only
"enable" having an effect for now.  Or we could add that value when
seccomp filtering becomes the default with -n remaining an alias for
"-n enable".  What do you think?

Paul