patch for seccomp

[jorge-lip]

Patch for seccomp on kernels >= 4.8.0
adds handle_tracee_event_kernel_4_8() to event.c

[walterbrebels]

We used proot and gdb to debug binaries within another sysroot. While it worked with the master branch and with an older kernel it doesn't work with a more recent kernel and/or this patch.

You can reproduce it with this command:

$ proot -R / gdb /bin/true
GNU gdb (Ubuntu 7.11.1-0ubuntu1~16.5) 7.11.1
Copyright (C) 2016 Free Software Foundation, Inc.
License GPLv3+: GNU GPL version 3 or later <http://gnu.org/licenses/gpl.html>
This is free software: you are free to change and redistribute it.
There is NO WARRANTY, to the extent permitted by law.  Type "show copying"
and "show warranty" for details.
This GDB was configured as "x86_64-linux-gnu".
Type "show configuration" for configuration details.
For bug reporting instructions, please see:
<http://www.gnu.org/software/gdb/bugs/>.
Find the GDB manual and other documentation resources online at:
<http://www.gnu.org/software/gdb/documentation/>.
For help, type "help".
Type "apropos word" to search for commands related to "word"...
Reading symbols from /bin/true...(no debugging symbols found)...done.
(gdb) run
Starting program: /bin/true 
warning: linux_check_ptrace_features: failed to kill child

Program received signal SIGSEGV, Segmentation fault.
0x0000000000000000 in ?? ()
(gdb) bt
#0  0x0000000000000000 in ?? ()
#1  0x0000000000000003 in ?? ()
#2  0x00007fffffffcffb in ?? ()
#3  0x00007fffffffd005 in ?? ()
#4  0x00007fffffffd008 in ?? ()
#5  0x0000000000000000 in ?? ()

With an older kernel and the master branch it works fine and when the application throws a segmentation fault we can catch it in gdb.

With a more recent kernel and the master branch we have to use PROOT_NO_SECCOMP=1 but gdb freezes when the application terminates. With a more recent kernel and this PR we get a segmentation fault as documented above.

[oxr463]

See suggestions here: #130 (comment)

[oxr463]

#include <linux/version.h> /* KERNEL_VERSION, */

From: #149

[romainreuillon]

What if the machine proot run on is not the same as the one on which it as been compiled ?

[oxr463]

If the kernel version doesn't match i.e. running on an older kernel, it will default to the old behavior.

Also, it is important to note that the user can fake the kernel version at runtime via the -k flag (1).

[romainreuillon]

Great !

[oxr463]

Reopening due to #106

TODO

• Create tests for seccomp:
  • with PROOT_NO_SECCOMP
  • without PROOT_NO_SECCOMP
  • kernel version >= 4.8
  • kernel version < 4.8
• Drop PROOT_NO_SECCOMP from travis.
• Merge changes from Termux
  • termux/proot@47138da
  • termux/proot@88b915e
  • termux/proot@793b096
  • termux/proot@0c1ab57
  • termux/proot@29a1f08

See: termux/proot#22, https://gitlab.com/proot/termux-proot

References:

• https://github.com/torvalds/linux/blob/master/Documentation/userspace-api/seccomp_filter.rst

• https://github.com/qemu/qemu/blob/master/qemu-seccomp.c

• https://git.kernel.org/pub/scm/docs/man-pages/man-pages.git/plain/man2/seccomp.2

[oxr463]

Debugging

make -C src
make -C tests &> log.txt
make -C tests V=99 &> verbose_log.txt

Gentoo

log.txt
verbose_log.txt

Alpine

log.txt
verbose_log.txt

log.txt
verbose_log.txt

[dmikushin]

As of the current master 5f780cb, I have to use PROOT_NO_SECCOMP=1 on kernel 3.10.0-1160.95.1.el7.x86_64, otherwise I get SIGSEGV (signal 11) in the verbose log. Thanks for the tip!