To: | bind9-public@isc.org |
From: | michal@isc.org |
Subject: | Drop seccomp support |
Date: | Wed, 29 Nov 2017 15:48:40 +0100 |
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.