3 ms·

Here I should mention my NCD programming language[1], originally developed for programming network configurations. Contrasted to networkd, it is an imperative p

• rjzzleep 13y ago
  that looks cool. but it also looks like it would be kinda complicated to make a point for it. 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?
  • ambrop7 13y ago
    This was not designed for end users, it was designed for programmers who want to implement their very specific network configuration requirements - in a language well suited for the task where dynamic configurations are easy to implement properly. One could implement an end-user solution using my language - the language is certainly powerful enough. But I don't have any plans to do that myself, writing scripts is good enough for me. 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.
    • rjzzleep 13y ago
      >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.
      • ambrop7 13y ago
        I was just saying that NCD is not particularly exposed to attacks in the first place. Yes, the DHCP needs to be moved outside, but everything else is pretty much a non-issue. The IPC that NCD can do (if you use it) is no more exposed than D-Bus is.
      • ambrop7 13y ago
        > a subset would be good i guess No. NCD was designed with the goal that you can program whatever the heck you want. By design, the core NCD language does not have any knowledge of network things. Only some commands do.
    • brokenparser 13y ago
      It should be possible for the DHCP client to run as a normal user by giving it capabilities. Barring that, one could employ privilege separation to isolate the sensitive part. 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.