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

[Dmitry V. Levin]

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.

>   - -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.

> 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.


-- 
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/20190713/4610f6f1/attachment.bin>