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.