aside from the fact that it's kinda complicated(for the end user), which would mean that your network daemon would probably run on top of it.
it also seems like it would in theory give a lot of attack surface. what is your opinion on the latter?
Attack surface? Not really. The parts of NCD which are exposed are basically:
- Integrated DHCP client (runs in the same process, as root). This is really just DOS attacks with a flood of DHCP packets, but the design ensures this may at most result in high CPU usage as well as DHCP not working, not in NCD stopping doing other things. But if the attacker can DHCP flood you he can also do worse damage with ARP poisoning. I don't believe I have arbitrary code execution bugs in NCD, especially not in the DHCP code. I'm a very careful programmer ;)
- IPC interface (request_server). The most questionable part here is probably the Lemon parser parsing NCDValues. Things like: ["key1":"val1", "key2":{"elem1", "elem2", "elem3"}].
Then there's also the security bugs the programmer writing NCD code does. Like, if he accepts an IP address obtained from a DHCP server without doing any sort of checks (in particular if overlaps with localhost / private network / VPN).
But basically, I don't think "possible security bugs" is a valid argument against any new technology. NCD is not inherently more vulnerable than any other system for network configuration.
it wasn't so much a case against "new technology", but rather a case against: "here's a full scripting language that runs as root, oh and btw it can print and run arbitrary commands"
to me it seems like ncd is almost too capable for non hacking / network debugging purposes. a subset would be good i guess.
Also root sounds bad. At least in linux you can always restrict it to things like CAP_NET_ADMIN, but i'm not exactly a linux security wiz, so i'm sure there's better things.
Secondly, the ARP cache poising thing is a straw man. Two wrongs don't make a right and besides, you can use /etc/ethers to mitigate such attacks.