
Introduction to networkd, network managment from systemd - polvi
https://coreos.com/blog/intro-to-systemd-networkd/
======
ambrop7
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).

[1]
[https://code.google.com/p/badvpn/wiki/NCD](https://code.google.com/p/badvpn/wiki/NCD)

~~~
rjzzleep
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
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
>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
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.

------
matteotom
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.

~~~
cnvogel
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.

------
brokenparser
"Hey Michael, systemd is going to handle networking!" His response:
[https://www.youtube.com/watch?v=31g0YE61PLQ](https://www.youtube.com/watch?v=31g0YE61PLQ)

------
rwmj
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.

~~~
tomegun
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.

------
ayharano
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.

