Hacker News Reader

Comment by dsr_ | Hacker News Reader

Here's a thing to ponder:

If this were not buried in systemd, but was part of a standalone dhcpd package, would it have been done better or caught earlier?

One of the major criticisms of systemd is that it wants to take over all system management functions. In order to do that it needs to offer at least minimally functional versions of all the services it pushes out. It should not be news to anyone that trying to do everything instead of integrating with existing projects leads to sloppiness.

This incident is evidence suggesting that other serious issues are lurking in systemd as a result of the actions naturally arising from their policy.

View on HN

I'm sure (but don't recall) Redhat's pump and ISC's DHCPCD have had CVEs; we all know BINDs resolver and ntpd had CVEs.

If one is going to rewrite all of these things, I would expect one to learn from the history and not make the same mistakes over again.

Nit: ISC's DHCP client is 'dhclient', not 'dhcpcd'. 'dhcpcd' is Roy Marple's DHCP client.

I would only expect that if the people rewriting everything were good programmers and said they were rewriting it to be secure. Most rewrites are done for non-security reasons are don't improve security.

Programmers should give appropriate attention to security regardless of whether they are doing either original work or a rewrite, and in the latter case, regardless of the reasons for the rewrite. I would not regard those who do otherwise as good programmers. Clearly, a DHCPv6 client within Linux' system administration suite is a case where security is an issue of the first magnitude.

Programmers should do a lot of things that most of them do not do. The statement was "I would expect..." and I replied that it doesn't make sense to expect those things because the vast majority of programmers don't know or care about security at all. We still see the same trivial SQL injections being written again and again on today's web, often by 20+ year programming "veterans".

The problem was in systemd-networkd, not systemd.

One of the more popular DHCP clients is 'dhcpcd', which was created and is maintained by Roy Marples, the creator of OpenRC. It's fine when someone wants to work on DHCP clients and init systems, unless that init system is systemd?

(And for the record, systemd integrates wonderfully with dhcpcd.)

dhcpcd is not solely or even primarily used with OpenRC, it just happens to be created by the same person. What systemd is doing is something else -- not recreating one thing because there is a lack of implementation diversity or the existing implementations are subpar, but reimplementing everything even when there are multiple existing reasonable implementations, just because.

Rewriting everything is fine, as long as it's not in C or similar insecure by design programming language, it doesn't invent DSLs on top of INI/YAML/JSON files, uses proper architecture with clearly defined boundaries and protocols, allowing custom application-specific management instead of forcing everyone into author's narrow worldview full of incorrect assumptions. So as long as you are not doing what systemd does.

Centralized management/monitoring in general sucks. People don't seem to understand the problem and keep reinventing new centralized architectures suitable for their own special cases, instead of addressing that on architecture level.

> doesn't invent DSLs

Systemd didn't invent a DSL. It uses the existing config language from D-Bus (whether or not you think that's a good language is another matter).

> uses proper architecture with clearly defined boundaries

What boundaries in systemd aren't clearly defined?

> allowing custom application-specific management

What do you mean by this?

This approach increases the attack surface because it is included in the most popular distros by default.

Reply on news.ycombinator.com