Drop seccomp support [RT #46729]

This ticket proposes complete removal of seccomp support from BIND source code due to a number of issues with both seccomp itself and the way it is implemented in BIND. Removal is planned to be announced in BIND 9.12.0 release notes and then performed in the next .0 release.

The reasons for suggesting removal of seccomp support from BIND are:

• Compiling an exhaustive list of system calls which should be whitelisted is very tricky for a piece of software as complex as BIND; while an application needs to declare a complete whitelist of system calls which need to be allowed, it cannot assume anything about what system calls libc is going to use in response to the standard C library calls issued (see e.g. open() vs. openat(), setrlimit() vs. prlimit()).

• Alternative mechanisms for achieving the same kind of protection exist, e.g. SELinux or AppArmor. Fine-tuning policies enforced by those mechanisms does not require any changes to be introduced into BIND's source code.

• For threaded builds of BIND, seccomp is implemented in a way which provides virtually no extra protection as the only thread which is protected using seccomp is the main thread which waits for libisc to exit its main loop; worker threads are not protected at all because seccomp is initialized after worker threads are spawned. However, this causes odd system test issues e.g. due to named getting killed by SIGSYS after it logs an "exiting" message, but before it gets a chance to clean up its lock file and PID file.

• For non-threaded builds of BIND, we are currently whitelisting over 60 systems calls, including open(), read(), write(), close(), mmap(), chdir() and unlink(). These system calls alone are enough for potential exploits to wreak havoc in the system, so such protection arguably does not limit the attack surface significantly.

• Considering planned implementation of hooks and enabling external hook modules to be loaded at runtime, either users will potentially need to locally update the seccomp system call whitelist if their module is going to use anything not currently on the list or we will need to provide hook modules with a way of adding extra system calls to the whitelist. Both of these options would further limit seccomp's usefulness.

[NOTE: Not copying the other conversation from RT, it could be looked up there.]