Sandboxing: How important is seccomp?
hmurray at megapathdsl.net
Tue Jul 12 00:37:07 UTC 2016
[For those not familiar with it, seccomp gives the kernel a list of syscalls
that the program is allowed to use. All others becomes illegal. So if a bad
guy finds a stack overflow there is (hopefully) a good chance that any code
he tries to run will crash.]
I've got it working on Intel. It doesn't work on ARM. More below.
This is likely to have a long tail of cases that I can't test. There is an
interesting tangle of which syscalls are used by various combinations of 32
vs 64 bit and the age of libc and kernels. I've been adding things to the
list as I discover them. There are probably obscure combinations used by
distros that I can't test and/or refclocks that I can't test may use strange
There is also the chance that things will change out from under us. For
example, getrandom was added to the 3:17 kernel. So if you updated your
kernel and glibc our ntpd would crash until we updated it or you disabled it
Assuming the environment supports them...
Should we set things up so so that droproot and seccomp are required at build
time unless you explicitly disable them? That just requires installing the
Should we set things up so that droproot is required at runtime?
I assume we add options to disable any runtime checks.
(Can we use -u root:root to say no-thanks?)
Both work on Linux. NetBSD supports droproot.
On ARM, it dies before it gets to our code.
[Thread debugging using libthread_db enabled]
Using host libthread_db library "/lib/arm-linux-gnueabihf/libthread_db.so.1".
Cannot access memory at address 0x0
Program received signal SIGILL, Illegal instruction.
0x76dabde8 in ?? () from /usr/lib/arm-linux-gnueabihf/libcrypto.so.1.0.0
#0 0x76dabde8 in ?? () from /usr/lib/arm-linux-gnueabihf/libcrypto.so.1.0.0
#1 0x76da84b4 in OPENSSL_cpuid_setup ()
#2 0x76fdeffc in call_init (l=<optimized out>, argc=5, argv=0x7efffd34,
env=0x7efffd4c) at dl-init.c:78
#3 0x76fdf0d8 in _dl_init (main_map=0x76fff958, argc=5, argv=0x7efffd34,
env=0x7efffd4c) at dl-init.c:126
#4 0x76fcfd84 in _dl_start_user () from /lib/ld-linux-armhf.so.3
Backtrace stopped: previous frame identical to this frame (corrupt stack?)
These are my opinions. I hate spam.
More information about the devel