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

[Dmitry V. Levin]

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:
> > > Hi.
> > >
> > > I want to apply GSoC again. I am interested in seccomp-assisted syscall
> > > filtering project.
> > >
> > > I introduce myself again.
> > >
> > > My name is Chen Jingpiao, a junior student in Guangdong Pharmaceutical
> > > University, majoring in Computer Science and Technology. I am familiar
> with C,
> > > Linux and tools (Git, vim, gdb, find, grep, diff, makefile etc.)
> > > I have accepted strace GSoC 2017 netlink socket parsers project.
> > >
> > > I will prepare the work according to the following step:
> > >
> > > 1. Understand how strace trace a program (or attach a process)
> > > 2. How seccomp work
> > > 3. How to handle special case:
> > > * architecture
> > > * personality
> > > * -f option
> > > * subcall
> > > 4. How introduce seccomp filter in strace
> > >
> > > I'm happy to hear your suggestions or get your help.
> > > Thank you.
> >
> > Please note that there is already some (seemingly abandoned) patch
> > available that tries to introduce the functionality in question[1],
> > as mentioned on strace's GSoC wiki page[2] (do you plan to use it in
> > your work or will do everything from scratch?).
> 
> Thank you.
> I want to work from scratch.
> 
> > I'm looking forward
> > to a more elaborate description of the proposal (for example, what are
> > expected limitations of seccomp filter (like its size) and what
> > functionality can be achieved there, how it integrates with other
> > features like path filtering and the upcoming filtering engine, what
> > are possibilities regarding optimizing BPF code for size). In addition,
> > I have a concern regarding conflicts with already set seccomp filters
> > or attempts to do so, what solutions could you propose in that regard?
> 
> In my understanding, this project is work with -e trace option to make
> strace
> run faster. Not introduce user command, it easy to integrate with other
> features.

Yes, a seccomp-based filter should be a transparent alternative
to the traditional filter implemented in strace.

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.

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

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.


-- 
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/20180325/9445a0ff/attachment.bin>