It breaks with the existing whitelists on the latest glibc and is
just too much maintenance burden. It also causes the most questions
for new users.
Something like openbsd's pledge() would be fine, but I have no
intention of maintaining such a thing.
Most of the value-gain would come from disallowing high-risk
syscalls like ptrace() and the perf syscalls, anyway.
ndhc already uses extensive defense-in-depth and wasn't using
seccomp on non-(x86|x86-64) platforms, so it's not a huge loss.
ndhc will fork off an ifchd child that it will communicate with via
pipes rather than by connecting to a SO_PEERCRED AF_UNIX socket.
The advantages include:
1. Simpler configuration. Much easier for users and packagers to set up.
2. Drastically less complex code for the ifch functionality. More code
is removed than added, and the result is a lot less complex.
3. Potentially better security. The ifch can only service the parent
ndhc process, and it is restricted to issuing modifications to
the single interface that ndhc manages.
4. Less memory used on systems that allow overcommit.
The downsides:
1. Possibly more memory used on systems that run multiple ndhcs and use
strict commit limits.
At the same time, use netlink rather than ioctls so that the
interface ip, subnet, and broadcast address can be set simultaneously.
This change reduces the netlink notification spam greatly.
The current code builds but isn't yet complete. Subsequent commits will
flesh things out and polish out some remaining issues.
Define _GNU_SOURCE in the CFLAGS.
Update the README.
Remove the duplicate Gentoo init script ndhc.sh that is in the root.
Remove DESIGN -- it's outdated.
initialization. Fetching if/address/index/mac mappings is done only once at
program init, so it is done synchronously as an exception to this rule.
Rewrite the netlink handling. Now uses NIH code that should be safe, small,
and correct. No external deps FTW.
