Sandboxing: How important is seccomp?

[Hal Murray]

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

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


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

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
(gdb) bt
#0  0x76dabde8 in ?? () from /usr/lib/arm-linux-gnueabihf/libcrypto.so.1.0.0
#1  0x76da84b4 in OPENSSL_cpuid_setup ()
   from /usr/lib/arm-linux-gnueabihf/libcrypto.so.1.0.0
#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?)
(gdb) 



-- 
These are my opinions.  I hate spam.