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

[Dmitry V. Levin]

On Sun, Jul 14, 2019 at 11:35:09AM +0200, Paul Chaignon wrote:
> 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?

I agree, enable/disable would be better in the long term.
btw, why -n has been chosen?


-- 
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/20190714/ee6467b3/attachment.bin>