Here I should mention my NCD programming language[1], originally developed for programming network configurations. Contrasted to networkd, it is an imperative programming language with a twist (backtracking) that makes it practical for this purpose.
Strictly speaking it can't be directly compared to networkd, which has a declarative configuration - until someone implements such a declarative config system with NCD. The goal of NCD is to allow hackers to program their network config however they want, not just in ways foreseen and implemented by their declarative config system.
NCD can already react to many kinds of events, including the basic network stuff (interface appeared/disappeared, cable plugged in/out), input devices (via evdev) as well as an IPC protocol which works with structured data (for GUIs and CLI control).
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.
>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.
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.
> 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.
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.
I wonder if Arch Linux will pick this up. They jumped head first into systemd a while back, but have also rolled out their own network config program, netctl. I think it'll be interesting to see whether they stick with that or switch to networkd.
Netctl is alrady the third implementation of networking scripts I'm aware of. The last one (netcfg) still seems to be working just fine. It's not an overly elaborate set of scripts for networking configuration, that already integrates well with systemd.
All these things tell me that it will probably not take long until Arch takes to take advantage of network configuration in systemd.
But then, for more complex, and more dynamic environments, people have used NetworkManager. If it will replace NM, which is a much more substantial piece of code covering a lot of the more complicated setups (VPNs, cellular, a lot of user-interaction), I don't dare to speculate about.
Interestingly, whilst everyone pushed for netctl on IRC when it was released, I asked a question the other day and the opinion was that netctl sucks and I should use NetworkManager, which has handier VPN support and has improved substantially.
My question is why this daemon needs to be included in systemd.git. It appears to be a separate service which could easily live in its own project, to live or die on its own merits.
We (the systemd developers) want systemd to provide the basic building blocks from which you can build an operating system. Networking is definitely one of these, so we want to include it by default.
However, you are of course free to use an alternative network management solution, and at least in the beginning we expect most people to stick with what they have. Distributions could easily ship networkd as a separate package, if they so chose.
A prediction I'll write down to check in two years:
My guess is that at some point Arch and Fedora will "officially" become Systemd/GNU/Linux (Systemd will become the required and system-equivalent component) while Ubuntu will start working hard on creating a sane, modular equivalent.
Basically with init, dbus (now migrating into the kernel), logging, authorization, resource control, networking, etc. the only big thing left to control is software installation. I expect Systemd-package to pop up soon. It's going to be convenient, technically good enough to adopt and integrated enough that some projects will become pretty much not installable on other systems without hacking the build (think replacing makefiles or something similar). It may be even a slightly-incompatible systemd-rpm.
The place where systemd will be annoying the most is servers - currently most of what they do concentrates on desktops. Specialised VMs will suffer from bloat of unneeded functionality (journal, dynamic networking, dbus, cgroups integration (people that need it will do it manually anyway), user sessions, ...) and this is the first place where replacements will start.
(deleted parent was wondering what will happen first: people freaking out that systemd becomes too integrated, or systemd becoming too integrated to create a linux system without it)
Ubuntu is following Debian on using systemd, "as soon as it offers a credible quality of service to match the existing init" (which might happen pretty fast): http://www.markshuttleworth.com/archives/1316
I don't see software installation unification happening any time soon. There are layers like packagekit that sit above package managers, though (but mostly under-developed because, well, what is the point?).
AFAIK, systemd makes sense in servers (possibly even more than in desktops), because of its support for container setups. Not sure, though.
Yes, they were also happy to adopt Gnome shell some time ago... until they came up with own solution. And they worked on another display server... until they came up with own solution. I expect them to go the same route again.
Upstart was started before sytemd unlike Mir and Unity (in comparison to Wayland and Gnome 3) and it's creator having come in support of systemd[1], Ubuntu's upstream, Debian, going with it and on top of that Shuttleworth already admitting defeat. I have to seriously doub that.
Is there any official development or user mailing list? I am trying to set both static IPv4 and IPv6 addresses, but I am able to set only the address, not their respective default routes. BTW, I am using Arch Linux ARM and systemd 210 just kicked into repositories today.
