Hacker News new | past | comments | ask | show | jobs | submit login
Ubuntu Systemd Vulnerability (ubuntu.com)
194 points by ingve on June 28, 2017 | hide | past | favorite | 234 comments

The most dangerous thing about systemd-resolved is that it exposes its own non-standard DNS resolution protocol over dbus, which the documentation recommends applications use instead of standard, interoperable protocols[1]:

> The native, fully-featured API systemd-resolved exposes on the bus. See the API Documentation for details. Usage of this API is generally recommended to clients as it is asynchronous and fully featured (for example, properly returns DNSSEC validation status and interface scope for addresses as necessary for supporting link-local networking).

systemd wants applications to depend on systemd-resolved so it becomes irreplaceable. This is very bad, because the first thing you should do on a system with systemd-resolved is uninstall it. The systemd developers are not qualified to write either DNS software[2] or C code that talks to the network.

[1] https://www.freedesktop.org/software/systemd/man/systemd-res...

[2] See http://seclists.org/oss-sec/2014/q4/592, which came out after Lennart Poettering had the hubris to call systemd-resolved a "pretty complete caching DNS and LLMNR stub resolver"[3] even though the dangers of DNS cache poisoning were already well known at the time.

[3] https://lwn.net/Articles/609740/

> This is very bad, because the first thing you should do on a system with systemd-resolved is uninstall it.

Thanks, I just realized that my Arch installation has nih-emd-resolved enabled as the default backend for glibc getaddrinfo and friends. This is how it happens:


I'm not responsible for any harm to systemd resulting from the use of this information ;)


And yes, the current version of the package is 232, built in January, so should be vulnerable.

Does anyone have any insight as to why systemd has its own DNS resolution API? That seems like a very strange decision. Is it really only so that systemd "becomes irreplaceable"?

It's more about dbus, really. They are trying to get rid of 'everything is a file' and move to a pub/sub service model.

"They are trying to get rid of 'everything is a file' and move to a pub/sub service model."

I thought we were trying to move towards "everything is a file" ... isn't that the goal of the plan9/Inferno movement ?

I thought that was the progressive direction in UNIX design.

We want to move away from "everything is a file" ?

Everything is a file ≠ everything is a blob/adhoc plaintext interface.

DBus is a much superior “everything is a file” abstraction, except DBus calls files objects and doesn’t special-case directories.

Quick comparison:

Inode — Client address

.. e.g. 3597293 — :1.32

Mount points — Well-known addresses

.. e.g. /proc/subsystem — org.foo.subsystem1

Directory/file hierarchy — Object hierarchy

.. e.g. /foo/bar/xyz — /foo/bar/xyz

Implicit RPC — Explicit RPC

.. e.g. IOctl or echo "foo" > /foo/bar — org.foo.Interface1.methodFoo(int, int, string)


.. sudo vs Polkit


> Everything is a file ≠ everything is a blob/adhoc plaintext interface.

Actually, yes, it more or less means exactly that. Everything is a file means your interfaces (i.e. object methods) are generally limited to open, read, write, and close. Of course you can synthesize whatever you want on top of that, but the basic contract relies on those primitives exclusively.

And this is better how exactly?

Ever try to use a dbus service from the shell? From any language that _doesn't_ rely on a binding to the C library? Therein lies your answer.

It's like ioctl. The ioctl interface is an abomination precisely because it breaks the open/read/write/close interface. Ever try to use an ad hoc ioctl interface from any language other than C or C++?

If all the world used the same programming language with the same control flow constructs then a strongly typed RPC interface would make a ton of sense. But it doesn't.

The everything-is-a-file contract works well for the same reason that IP works well: because it pushes the complexity to the edges, and when the technology changes you don't need to upgrade every piece of middleware.

Almost every modern language supports open, read, write, and close from day 1, giving you the necessary primitives to communicate with anything supporting that model. Of course, maybe batteries aren't included and you have to do some grunt work. But that's often the interface designers fault. Opening a TCP connection on Plan 9 is as easy as a single open call, vs multiple complex system calls using a more typed interface like the BSD Sockets API.

Even dbus can be exported through the file model. Theoretically you could expose dbus through the filesystem namespace using something like FUSE. And, actually, here's an attempt at that: https://github.com/sidorares/dbusfs Which goes to show how flexible the open/read/write/close model truly is.

> Ever try to use a dbus service from the shell? From any language that _doesn't_ rely on a binding to the C library Therein lies your answer.

There are many libraries that do not bind to libdbus. GLib’s, QT’s and outside of C/C++ you have native python (txdbus), native javascript (node-dbus, which is btw powering the dbusfs you linked) and native C#/mono. That’s just off the top of my head, I’m sure there are many more.

As for shell, I am not a fan, obviously, but qt-dbus (and the glib one) has existed for a long time and busctl is even nicer. Works just fine if you just need the client functionality.

DBus lends itself to something much more powerful like Microsoft’s Powershell (but without the CLR). Bash is obviously designed for filesystem interface, it also is not a great fit for SQL. Doesn’t mean SQL is shit.

> Which goes to show how flexible the open/read/write/close model truly is.

It‘s useless, not flexible.

Everything has some ad-hoc implied interface, documented who knows where, if at all, and this giant hack is somehow something to admire?

Garbage-in, garbage-out. I’ll take DBus any day.

> Theoretically you could expose dbus through the filesystem namespace using something like FUSE.

You can expose the filesystem via DBus as well (e.g. org.gtk.vfs). Shows you how flexible DBus is.

At this point in the discussion, I am reminded of http://gentooexperimental.org/~patrick/weblog/archives/2014-...

> Everything has some ad-hoc implied interface, documented who knows where, if at all, and this giant hack is somehow something to admire?

Jumping ship to DBus is not the solution to this problem. The problem is that the current incarnation of everything-is-a-file is not radical enough. Reiser4 had some very interesting ideas with regards to unifying the many different information namespaces, it's a shame they never became mainstream. I'm hoping that future innovation won't be disinfranchised by people who want to abandon filesystems entirely and switch to another ad-hoc model that isn't really much better.

[ I could've sworn I already replied to this comment before. Weird. ]

> DBus is a much superior “everything is a file” abstraction, except DBus calls files objects and doesn’t special-case directories.

The benefit of "everything is a file" is not any of the things you listed about the API and concepts, because as you noted all of them are applicable to basically any way of structuring information in a database or message bus.

The argument for "everything is a file" is that you can create complicated processes without the need for any programming, by grouping together many small programs that all operate on the same interface (the filesystem) and thus you can chain together pipelines. Effectively every UNIX program operates on the filesystem at some level, so these benefits translate to almost any program unless the developers specifically work to make it difficult.

So, DBus will always be poorer as an "everything is a file" abstraction as long as it doesn't have the equivalent of the coreutils (and every other program buys into it as well). There are many other problems with DBus, but if you're going to go about it from the "well, DBus is basically like a better filesystem" angle then this is the main issue with that argument.

> Implicit RPC — Explicit RPC .. e.g. IOctl or echo "foo" > /foo/bar — org.foo.Interface1.methodFoo(int, int, string)

I think most people will agree that ioctls are a very bad tool for implementing filesystem concepts in an out-of-band way to avoid making them consistent with the filesystem. The problem is that operating systems (and filesystems) haven't gone far enough with the everything-is-a-file concept. And personally I think that the best way forward for everything-is-a-file is that more and more things get put into the filesystem namespace. Reiser4 was a very interesting concept because the idea was to make it so that various different things could be combined so that any random UNIX tool could operate on other namespaces. Effectively you could use `cat` and `tee` to change the owners of files and things like that because the metadata namespace was part of the filesystem. Plan9 has some unrelated improvements to the filesystem namespace which also improves the coverage of the filesystem to be more cohesive.

Moving away from the filesystem would be the death of the UNIX vision of having everything pass through one interface and everything being able to interact with that interface. UNIX made many mistakes, plan9 made some mistakes (though less), and I'm hoping that operating systems continue to innovate on these concepts. It's a shame that POSIX is stifling this sort of innovation by making everyone complacent in coming up with new improvements to the base set of abstractions we're using.

Because the basic glibc resolver is still in the last century. (No cache, no DNSSEC, no link-local multicast name resolution, no concept of per-interface DNS resolution worlds, and so on. See the relevant part of the NEWS file: https://github.com/systemd/systemd/blob/master/NEWS#L3966 )

See also:


Cache and DNSSEC do not require a non-standard DBUS API.

LLMNR and per-interface DNS resolution are features that very few applications need. Those that do can link with their own resolver libraries.

nscd, which is part of the GNU C library, is a cache.

Moreover: Strictly speaking what is in the C library, to use the jargon, is a stub resolver; with all of the things that you mention not actually belonging in the C library in the first place.

Yes, you're of course right.

And Ubuntu used dnsmasq as a caching resolver for quite a long time. (Via using in /etc/resolv.conf)

systemd-resolved is sort of the same thing (and it listens on, which doesn't require the DBus dance that the nss plugin does)

I don't know why systemd reinvented the wheel (nscd), but probably because nscd lacks a DBus API.


Ah yes, being called a troll by a systemd dev. At this point i would consider it a badge of honor.

An opinion backed up with facts and sources is trolling? Go look in a mirror next time you troll hunt.

A year ago, there was this:

https://lists.dns-oarc.net/pipermail/dns-operations/2016-Jun... discussed at https://news.ycombinator.com/item?id=11845051

The 3rd bullet point is worth reading several times, in order to take in the absurdity of it all.

Good grief.

On the other hand, it improves safety and security for many users.

Because on most distros, using unbound or BIND9 as local DNS server, they bind to all interfaces, publicly.

Which is the reason why DNS amplification DDoS even is possible.

I’ve seen it often enough happen, and basically every person who’s set up their own servers has made the mistake of leaving the defaults.

This has nothing to do with this conversation. DNS recursors are not being discussed. This is strictly about DNS resolvers.

But who runs a DNS server? 99% of users only do DNS resolution and for that you don't need to run a DNS server on your system.

Many people run a DNS server to cache DNS responses locally. And they don’t want to expose the DNS server publicly. systemd-resolved does that, you can’t even expose it accidentally.

But many distros actually install a DNS server by default, usually unbound or BIND9, and while some bind it to localhost, many bind it to all interfaces.

As you said, that’s not necessary for most users, yet, major distros do it.

> cache DNS responses locally

I believe there is a built-in solution in glibc:


Which distros install a DNS server (and enable it) by default? I've never seen this.

dnsmasq has been installed as a local DNS cache on Ubuntu and other Debian derivatives for many years. /etc/resolv.conf normally points at localhost.

It only listens on localhost though ( by default), so it's not possible for it to be abused for dns amplification attacks.

IIRC dnsmasq still listens on all interfaces for some reason

Which is exactly the issue I mentioned.

You get on some distros by default something that that makes you subject to DNS amplification attacks.

It is supposed to reject requests from the addresses it does not listen on. I just found it strange that it binds on all interfaces regardless.

I’ve noticed it respond with an error packet – which ended up being used for DNS Amplification nonetheless.

I thought DNS was connectionless? Don't all DNS clients have to bind to UDP port 53 to function correctly?

It's not the port that matters; it's the interface. A caching DNS service for a simple desktop experience should only be listening for queries on the localhost interface (lo).

FreeBSD has named. In 9.0 it's BIND. In 10.0 & 11.0 it's Unbound.

You need to explicitly enable it, and it only listens on localhost by default.

On Debian, and I assume its derivates, Unbound will by default only listen to localhost. What distribution has changed this, because I think that is also the upstream default?

Ubuntu 14.04 and Debian old-old-stable listened on all interfaces.

The versions provided by most cloud hosters are also misconfigured to listen on all interfaces.

Hm, as far as I can tell Debian has never shipped a version which listens to something other than localhost by default. The upstream fixed this in 2007, before Debian started packaging Unbound.

Every person who has followed my and Daniel J. Bernstein's recommendations when setting up their own servers will not have done any such thing. We have been giving these recommendations for the better part of two decades now.

* http://jdebp.eu./FGA/proxy-server-ip-addresses.html

* http://cr.yp.to/djbdns/run-cache.html

> systemd-resolved could be made to crash or run programs if it received a specially crafted DNS response.

As nation states are hording zero days, and the security sheep herd insists updates are the way to go, I have never been more convinced that sticking to an OLD AND TRUSTED source code base for your infrastructure is the way to go. You can pop layers on top of that to get newer software running if you like, but trying to keep up with this psuedo-rolling-release avalanche of crap coming down the pipe is not a fair burden for administrators to handle. The devs need to shove it because we don't want it. I am hoping the next economic recession starves out the enthusiasm for disposable infrastructure and "move fast and break things" and businesses can go back to focusing on long term stability.

"I have never been more convinced that sticking to an OLD AND TRUSTED source code base for your infrastructure is the way to go."

I recently (2016) built a little network appliance for a specific task that needed to be safe and secure.

I used FreeBSD 4.11.

Are you sure it has no remote vulns since it's been discontinued or did I just prove Poe's law?

I think that's called security by obsolescence. Not sure how well that actually works. Root kits don't just disappear and FreeBSD 4.1 isn't as obscure as, say, VMS. But as long as there are no remote vulnerabilities it's probably no worse than a typical Linux install, in the sense that both would be trivially rootable once you get your foot in the door.

Usually with BSD you can apply new patches to old systems without any trouble. No need to upgrade everything.

Maybe FreeBSD is different, but I've run OpenBSD for 17 years and this is definitely not the case for all BSDs. Because OpenBSD is a cohesive system they're not afraid to do aggressive refactors. Which means subsystems can change drastically within just a few release cycles, meaning you can quickly lose the benefit of further fixes.

For example, just today Theo announced that he's staging the removal of TIOCSTI, the perilous ioctl that allows injecting data into a process group TTY. It's a huge break with historical BSD. That means if there's a TIOCSTI exploit found next year (say, in the NetBSD or FreeBSD code) that effects OpenBSD 6.0, there won't be an OpenBSD fix to backport; you'll have to craft one yourself and maintain it going forward.

NetBSD imported Lua 5.1 (IIRC, or maybe Lua 5.2) into their base, then in later releases upgraded it to Lua 5.3. the difference between Lua 5.1 and Lua 5.3 is like the difference between Python 2 and 3. Plus, Lua 5.1 is completely unmaintained at this point. If you're on an unsupported NetBSD release don't expect any fixes coming down the pipe for Lua 5.1.

But I admit that FreeBSD is definitely not OpenBSD, for better and worse, in terms of the pace of major refactoring work.

Current situation in Debian:

Jessie is not vulnerable.

Stretch is vulnerable (no patch yet), but systemd-resolved is not enabled by default.


Is anyone else fed up of systemd yet? Increasingly Jack of all trades, master of none. Can we have something new instead? Or maybe Red Hat can put Pottering back in his holster?

I'm sick of Linux Servers I use, being "improved" with Desktop implementation in mind.

Yes. I've burned hours on systemd related problems that just didn't exist before. From DBus message delivery failures, debugging things that haven't broken for 20 years (which has incidentally got MUCH harder) to the whole shit crock that is NTP and locale management. That and the whole desktop buggery that has been going on for the best part of 8 years now has really put me off. To be honest you haven't really experienced systemd's fuckery until you have a hosed box. It's like negotiating a boot with a pigeon. Any other platform is ZERO hassle and that includes windows, OSX, freebsd, openbsd etc.

And you can't criticise it anywhere (watch the downvotes).

The problem is it lacks the mysterious as in Zen and the Art of Motorcycle Maintenance class "quality". Merely glitter around a turd.

However we're stuck with it so it's suck it up or move on.

On the subject of moving on, you could run FreeBSD to run your servers. Much lower resource overheads, native ZFS, simple service management, some documentation worth more than toilet paper and the best thing of all, more sleep at night. Now there are binary updates and packages it's pretty easy. No more make world of any of that stuff.

And you can't criticise it anywhere (watch the downvotes).

Nonsense. HN has plenty of comments criticizing systemd, some of them in this very thread. They just have to be substantial, not merely empty rants or technically wrong claims.

I apologise. This is the first time I've criticised systemd on HN. I had a massive rant on another site a couple of years ago when CentOS 7 dropped about the catalogue of failures I had been through with systemd, completely backed up with evidence and bug reports and it was hammered by downvotes instantly.


I noticed that. Amazing.

I'm replying to myself because the original comment I was replying to was flagged, as it mentioned RH employees down votings.

Its the little things isnt it.

This is interesting and lines up with the time zone offset on my last rant a couple of years back. Peak in upvotes UK afternoon followed by downvote pummelling at around 4pm UK time. Without wishing to don the tinfoil hat too much, actively squashing critical discussion on your product is a dick move if it's true.

This has got so bad on some parts of reddit they removed the voting buttons.

Any other platform is ZERO hassle and that includes windows, OSX, freebsd, openbsd etc.

I'd add Slackware to that list, at least for now. I've switched some servers to OpenBSD and a few others to Slackware, plus I've switched to Slackware for a laptop I use.

I'm cautiously optimistic that Patrick will keep systemd out of Slackware for the foreseeable future. It is after all one of the most BSD like Linux distros available.

Interesting. I haven't used slackware for many years, so far back in fact that it had to come on CDs because I had a dial up. Will take a look in that direction this evening.

I hadn't used it since the mid-nineties but it was the first distro I ever used and, really, my first exposure to any Unix like system. My first copy came on a CD in a book I bought at a software trade show.

I joined a company that used Debian for everything so I ended up switching to it for many years. When systemd came along I decided to look around again; thus my foray into OpenBSD and my return to Slackware.

If you do give it a look you may be surprised at how little some things have changed. Packages are kept pretty current but the installer and the basic tools are surprisingly similar to the way they were when it was first released in the early nineties.

Excellent. Downloading now :)

I ran NetBSD and OpenBSD on old sun kit in the late 1990s and early 2000's followed by Debian and then CentOS. FreeBSD got a look in persistently on the side. I'd rather like a step back to the sensibility of times past when you chucked something out and it just did its job until something blew up :)

I'd rather like a step back to the sensibility of times past when you chucked something out and it just did its job until something blew up

Then I think you'll love Slackware!

Add Void Linux to the list, it uses runit.

I'll probably switch to Void Linux when the next Ubuntu LTS comes out. I'm running Ubuntu 16.04 on my laptop right now.

Didn't Docker switch to using Void as basis for their container images?

No, alpine. But running systemd in Docker has never /really/ worked (except if you're running on RHEL because they have a bunch of patches to make it work) due to how much shit systemd does that makes it hard to run in a container. Even systemd-nspawn (their container runtime which runs systemd inside the container) doesn't work in a lot of cases.

LXC is the only runtime I'm aware of that actually runs systemd inside containers well, but they had to do a lot of unholy shit to play nicely with systemd.

runc has had countless issues with systemd thinking that it owns the system and it messing with container cgroups.

And don't get me started on the fact that cgroupv2 is specifically designed to only work if you have a global management process for cgroups (can you guess what management process that is?).

And surprise surprise, the current cgroups maintainer is a Red Hat employee.

I'm not saying it is planned, but i wonder if there is a echo chamber effect going on...

> And surprise surprise, the current cgroups maintainer is a Red Hat employee.

Tejun used to work at RedHat, he's at Facebook now and I believe he was working at Google as well. However, he also does contribute to systemd development (recently he got a patch merged that broke every container runtime because they switched to a "hybrid" cgroupv2 setup in v232 which caused countless issues).

He who controls the spice....

In in this case, the source...

Yes, you should not get started on that, because it is a falsehood and not actually a fact.

* https://jdebp.eu/FGA/systemd-documentation-errata.html#Contr...

* https://news.ycombinator.com/item?id=11845867

There's no need to lecture me, I am very familiar with cgroups, having contributed to their implementation and also maintain runc which is a container runtime (that obviously uses cgroups quite heavily). I've also discussed these issues with other container runtime developers such as the LXC folks and kernel developers.

So let's talk about the API. First of all, cgroupv2 requires a single hierarchy. This means that if systemd is using cgroups for managing services, you cannot use cgroups for anything else because systemd will get confused if you create any new hierarchies. You may argue this is a bug in systemd, but I would argue it's because you can't have named cgroup hierarchies in v2 (like you could in v1, which is what systemd uses on v1).

But ignoring that "slight" issue, how about we talk about the no-internal node constraints and how subtree control works. First of all, in order to use a cgroup controller you must have all of your ancestor cgroups have that controller activated. So if systemd decides to not use a controller, then you can't use it either (without messing with things that systemd thinks it owns). But ignoring that, let's say you want to create a new cgroup under inside your user session (we've already established systemd won't like that, but let's assume that systemd plays along). You can't just create a new subcgroup (you won't be able to use the controllers), you have to create two and then move all of the other processes into one and then the process you wanted to control into the other. While this may sound okay, you have to realise that as a container runtime you now have to mess with processes that you have no control over or idea what they do. Not to mention that there's no way to atomically move all processes into a cgroup (so there'll be race conditions in trying to set this up).

The "delegation" model of cgroupv2 is effectively based around the systemd delegation model, where the higher level has to semantically grant you the right to manage your own resources. What kind of resource management system requires you to request the right to manage your own resources? prlimit(2) doesn't do that. cgroupv1 somewhat had this issue as well, but there is another cgroupv2 limitation added that actually means that even if you have write access to a child cgroup you still need to have write access in your current cgroup in order to move it into the child. Write access to cgroups.proc is actually a privilege in cgroups, so giving users access to this won't always be desirable, but it also further bakes in the management process design.

I've talked to Tejun on the mailing lists, and it's very clear that he prioritises the model of having a higher level process managing cgroups. In discussions about making unprivileged subtree delegation (something that is necessary for rootless containers to use cgroups) he made it clear that he isn't interested in the feature because it will cause systemd issues because it manages all cgroups on a system.

There's actually even more stuff you have to do to manage cgroups if you're not systemd by the way. I've talked to some LXC folks and we collated a list of 12 of different cases and things you need to deal with in order to use cgroupv2 effectively (and all of them break rootless containers, as well as making container runtimes very "noisy neighbours" as a result). cgroupv1 (despite its downsides) had none of these issues.

The only current user of cgroupv2 is systemd, and they've had several instances where they broke every container runtime because they flipped the cgroupv2 switch early.

Yes this was a rant, but I'm really tired of people defending this. cgroupv2 did make some good decisions, but then followed up by making some truly awful ones.

No-one defended cgroups. What you said about a single global management process was just plain wrong. I do find it amusing that you erroneously think that other people are lecturing you, by the way. (-:

A control group on the machine in front of me tells me that you are wrong about two more things.

    jdebp %ll -a /sys/fs/cgroup/service-manager.slice/user-services@.service/user-services@jdebp.service
    total 0
    drwxr-xr-x 6 jdebp root  0 Jun 29 18:17 .
    drwxr-xr-x 3 root  root  0 Jun 29 18:17 ..
    -r--r--r-- 1 root  root  0 Jun 29 18:18 cgroup.controllers
    -r--r--r-- 1 root  root  0 Jun 29 18:18 cgroup.events
    -rw-r--r-- 1 jdebp root  0 Jun 29 18:17 cgroup.procs
    -rw-r--r-- 1 root  root  0 Jun 29 18:18 cgroup.subtree_control
    drwxr-xr-x 2 jdebp jdebp 0 Jun 29 18:17 me.slice
    drwxr-xr-x 2 jdebp jdebp 0 Jun 29 18:17 per-user-manager-log.slice
    drwxr-xr-x 3 jdebp jdebp 0 Jun 29 18:17 service-manager.slice
    drwxr-xr-x 2 jdebp jdebp 0 Jun 29 18:17 system-control.slice
    jdebp %                                                                              
Unprivileged subtree delegation exists, that being a control group delegated to my account which has a whole subtree of further control groups in it, managed by multiple unprivileged processes. Your problem with "rootless" containers is not because of the non-existence, because Tejun Heo "isn't interested", of something that visibly exists. That's clearly not a correct description of the situation at all. Furthermore, https://lkml.org/lkml/2017/6/25/4 and https://lkml.org/lkml/2017/6/25/6 tell me that far from "isn't interested", Tejun Heo is interested in subtree delegation to unprivileged users. After all, xe is fidding with it right now.

systemd is not the sole user of version 2 control groups.

> A control group on the machine in front of me tells me that you are wrong about two more things.

But the problem is that the slices you showed are given to you by systemd. If systemd didn't want to give them to you for whatever reason, you couldn't use cgroups.

And you've not responded to any other part of my comments that relate to how the design of cgroupv2 is clearly geared towards management processes controlling subtrees as opposed to programs controlling themselves (the key point being that the root tree has to be controlled by someone).

> Unprivileged subtree delegation exists

But it requires a privileged user to "allow" it, making it less useful in most cases because it has to be automated (allowing for possible exploits) or done manually (not useful).

> Tejun Heo is interested in subtree delegation to unprivileged users

That's very odd, and is not the impression I got after discussing these issues with him last year. In particular I proposed something like his "nsdelegate" patch in early 2016 so it's nice to see that he's come around on that topic. But if he's changed his mind, that's great! Note though that the first patch is not directly related to unprivileged subtree delegation.

> systemd is not the sole user of version 2 control groups.

Can you give an example? I'm also fairly certain they're the only user of "hybrid" cgroup versions.

> But the problem is that the slices you showed are given to you by systemd

No, they are not. I did say that that control group told me that you are wrong about two things, the second being that systemd is not in fact the sole user of version 2 control groups. That should have been a major tip-off that systemd was not involved in that control group at all. (-:

> Can you give an example?

I actually did, two messages ago. Here's the hyperlink again.

* https://news.ycombinator.com/item?id=11845867

> However we're stuck with it so it's suck it up or move on.

This here is the hubris and arrogance of the entire thing.

I take heart that in the linux community, there is enough technical skill to come up with a viable, more in spirit of linux alternative. And I believe that I shall see the day where it is implemented. Lenny P and the gang should be less arrogant, and better at improving their product with this in mind. No one needs red hats "buy in" for this.

Thing is that none of them have the backing of Red Hat's finances. Thus they can'ẗ keep up with the churn that systemd and other RH backed projects produce.

This is why we need standards and APIs which are immutable. It doesn't matter what the implementation is then.

The whole of systemd is a comedic fuck you to POSIX and the mentality of a system which is standardised.

This is exactly why I've moved (and am in the continuing process of moving) more and more stuff over to BSD. Standards matter. Compliance with POSIX and other common standards and conventions are what made the success of Linux possible, and I find it disturbing that the new generation of RedHat developers are keen to tell us that it's old hat and is no longer important. But they are forgetting much of the history and the reasons for it.

Linux didn't get to where it is by throwing its weight around and dictating to others (at least, not much). Its success came from interoperability with everything, making it indispensable glue, and its adherence to standards was an integral part of that. As mainstream Linux becomes more insular and controlled by a single vendor, it becomes correspondingly less useful and less desirable. I don't want to be locked in to a RedHat world any more than I wanted to be tied to Solaris or HP-UX. I get occasional PRs for my software demanding that I add systemd-specific functionality, with the assumption that it's the only thing that matters, and people get annoyed when I refuse to compromise the portability of my already-standards-compliant software with Linux- and systemd-specific hacks.

One doesn't win a game of chess by moving all the pieces at the same time.

In case you didn't notice, on iOS 11 and High Sierra the new network APIs are only available as Cocoa APIs there is no plan to support them at POSIX level, while on Google side there are these little things called Android and Android Things, both with a locked down NDK, with Fuchsia on the horizon.

So I know on which side I am betting as winner for this chess game, given that Apple and Google seem to getting all the pieces with their moves.

Proprietary stuff comes and goes. These are merely the latest in a long line of proprietary APIs. They were not so "little" in their time as well. This seems to come and go in cycles; maybe the new generation of developers will come to realise the folly of vendor-specific lockin just as the previous one did.

These new APIs will either stand the test of time and become standards in their own right (POSIX, after all, is codifying existing practice from multiple vendors). Or they will die with the end of life of the products using them.

It's worth noting that POSIX is the fundamental basis of all these products. It's not perfect, and there's certainly room for new revisions or even a complete replacement in the longer term. But open standards are worth fighting for any using, given the alternatives. We got the current open standards through it becoming a requirement that vendors provided them and supported them, and that came from grassroots developers pushing for it. The current big players will eventually have to do the same, and we can all play our part pushing them to do so.

POSIX is stuck on replicating a PDP-11 experience of CLI and daemons applications.

Not everyone wants to live in the past.

Vendors come and go. Standards don't.

Ah, the sweet memories from CORBA, Usenet, Token Ring, Gopher, PHIGS, Taligent....

Stardards are only relevant as long as the industry cares to use them.

I can use all of those today or develop a new implementation if I want.

I actually developed and deployed an instance of a new GOPHER server recently. I was surprised to see requests in its access logs.

Sure you can, I doubt anyone would care, though.

That's a trifle unfair. A lot of this area was intentionally not addressed, for various reasons best laid out in contemporary writings on the subject, by the POSIX standardization effort.

I hate to point out that LOTS of Linux Distros did not and do not have Red Hats finances. People have been contributing to it for nearly 20 years just fine.

Not sure how you could even think that people need Red Hats finances to create something in linux that actually functions, and is worthwhile.

True for initial implementation of individual components. But RH employ developers that can sit full time and churn the interfaces (not necessarily nefariously) between the components such that only their components stay in sync.

What systemD has turned in to, is FAR out of scope, for what RH probably gave encouragement for. This will boomerang back some day.

I've been against systemd since day 1, because implementation issues aside, the entire concept is flawed and totally against UNIX philosophy: do one thing and do it well. UNIX, and by extension Linux, succeeded because of this philosophy.

It's also fairly transparent that RedHat would like Linux to be more obfuscated so that more enterprises will have to depend on it for support. But that's no surprise. What was surprising was that the Debian foundation not only opted to adopt systemd, but did so long before it was anywhere near proven to be stable, reliable code. This is contrary to their longstanding methodology. Ubuntu's adoption of systemd was simply the result of following Debian upstream. If only enough people could organize Debian to reverse course on systemd, if only until systemd proves to be stable and reliable (likely never). However, let's not pretend this is the first time that Linux has deviated from traditional UNIX and compatibility. There's always been Linuxisms, systemd is just by far the most egregious case.

FreeBSD has really come of age with pkgng though, and I'm happy to see it garner more attention now due to systemd woes. It has always excelled in certain ways, which is why Whatsapp was able to scale to millions of connections on a single box way back in 2012, its process/thread scheduling resulting in more responsiveness under load, better packet filtering, containerization much earlier on (jails), native ZFS, etc.

> It's also fairly transparent that RedHat would like Linux to be more obfuscated so that more enterprises will have to depend on it for support.

This is not a fair criticism to levy against an entire Linux distro company. There are many people at RedHat, SUSE, etc that very much cafe about the future of the Linux ecosystem and abhor the idea of obfuscating the operating system.

Sincerely, a SUSE developer who abhors the idea of obfuscating the operating system.

It's fair if it's the strategy as envisioned by the company's leadership. Employees of that company not sharing that vision does not change that. If anything, the employees should bear some culpability for working in support of that vision, even if they don't agree with it.

David Strauss is one of the systemd developers that don't work at Red Hat. It has its problems too: https://www.agwa.name/blog/post/thoughts_on_the_systemd_root...

Not to mention Kay Sievers which was even hated by Linus Torvalds: https://lkml.org/lkml/2014/4/2/420


I would understand if the products are actually good, but in case of systemd...

I wonder why Poettering chose Sievers in the first place.

The message which triggered this flaming is worth reading.

The answer is to leave the mainstream linux ecosystem, sadly. Slackware has been good to me. Openbsd is nice. Rolling your own userland is as possible as it's ever been. Maybe it's time to leave.

Let's face it: systemd is a bad design... The solution I found: FreeBSD and OpenBSD !

There are Linux distros that still have not succumbed.

None that I would use in production (as a sysadmin)

I've been toying with GuixSD recently and really love the immutable system configurations.

There are some caveats, but I would not mind using it on production servers. Sadly I haven't been able to convince my colleagues yet.

Not even a slackware?

maybe if they had package dependencies sorted out. they didnt last time i checked.

Could have sworn that i have seen companies opt for Gentoo in production, because they could tailor the end result specifically to their needs...

Slackware ?

i believe there's a debian fork around that doesnt have systemd... https://devuan.org/

But does not the FreeBSD project even more focus on memory unsafe languages (C) and is more monolithic then Linux distribution in general (userspace must match kernel).

No more so than a Linux distro does.

With the latter, you're referring to base. FreeBSD isn't really any more monolithic than your average distro in that regard though; it's just that with some services, the userland, and the like it (historically) made sense to maintain with particular stable versions of the kernel. Base is being slimmed down where possible though: bind has been replaced with unbound, dma is likely going to replace sendmail in FreeBSD 11, IIRC, and now that pkgng is proven, the process of packaging the base system should be complete for FreeBSD 12, which will allow freebsd-update to be (mostly) replaced.

I assume the comment you are responding to was about the init-system and in extension to the much more straight forward design and implementation of the overall system.

FreeBSD is, like all(?) other Unices written in C, as is most of the userland.

> userspace must match kernel

Just as far as it is true for Linux. If the interfaces don't change, the userspace tools will happily talk with any kernel. In now 19 years of FreeBSD usage on all my servers and on my laptop I ran into problems caused by a mismatch kernel<->userspace maybe 3 times. OTOH, the comparison is unfair with BSD-boxes reaching uptimes > 1 year easily.

Perhaps, but there's no systemd, which is a huge win.

You might like suckless.org

Memory corruption...

Someone would ask this sooner or later, so.. why is this written in C, really?

Nah, more like why do systemd include anything to do with DNS at all.

The shoggoth keep sprouting pseudopods as devs gets bored and think they can reimplement a time tested daemon in a weekend.

> The shoggoth keep sprouting pseudopods as devs gets bored and think they can reimplement a time tested daemon in a weekend.

"Ph'nglui mglw'nafh Cthulhu Raleigh[1] wgah'nagl fhtagn" ("In his house at Raleigh, dead Cthulhu waits dreaming.")

1. I'm so sorry, but I couldn't keep myself from punning Red-Hat-sponsored systemd with the Cthulu mythos. For the non-Lovecraft fans, the original city is named "R'lyeh"

Lovely. I actually confuse the two from time to time.

Exactly — rewriting a time tested daemon written in an unsafe language to an untested daemon in the same unsafe language. The worst possible option.

How else would you get DNS responses in XML over DBus? ;)

DBus only uses XML for its introspection interface. There’s really no reason why you couldn’t switch it to anything else like tomorrow.

Specifically, DBus does not use XML for any message passing or data serialization. It uses its custom binary on-wire format.

Also to consume or provide DBus services you do not need to interact with any XML whatsoever (except maybe for Polkit but that’s not DBus).

> There’s really no reason why you couldn’t switch it to anything else like tomorrow.

Except backwards compatibility? Something that any user of a supposedly-universal IPC bus requires out of the gate?

> It uses its custom binary on-wire format.

Even better, as we all know that custom binary on-wire formats have been proven to be more secure than any other option. Especially when written in C and exposed to a processes of all privilege levels.

> Except backwards compatibility? Something that any user of a supposedly-universal IPC bus requires out of the gate?

You can put DBus server behind a proxy that handles that for you. The XML format is very simple and it doesn’t change.

My point was simply that XML use is very limited, not exposed by any high-level APIs and can be easily ignored.

XML is only used for introspection, a debug protocol on top of DBus.

> Even better, as we all know that custom binary on-wire formats have been proven to be more secure than any other option. Especially when written in C and exposed to a processes of all privilege levels.

DBus is a message-passing protocol. You can write it in anything you like.

You could have DBus server that talks Protocol Buffers or JSON if you like, as long as you provide gateway for legacy clients.

> My point was simply that XML use is very limited, not exposed by any high-level APIs and can be easily ignored.

Saying "you can change it to whatever you want" is not a helpful thing to say. I understand your point (it's not "baked in" or wahtever) but you're not helping your cause by stating that "oh, we could just change this part of the protocol whenever we want and it would all just work". Because it gives an aura of instability and "we can move fast and break things" in my eyes (even though DBus has been around for a long time).

> DBus is a message-passing protocol. You can write it in anything you like.

The message passing daemon is written in C, and kdbus is a plan to put it inside the kernel (written in C). Just because "you can write it in whatever language you want" doesn't change that it is currently written in C, and I doubt that anyone is going to rewrite it in Rust any time soon.

Again, I understand that DBus is a protocol and an implementation and you can swap out the implementation if you want. But how many implementations currently exist? One. So currently the dangers of having custom binary formats in C is a valid concern even if you might be able to switch to some other implementation in the distant future.

> But how many implementations currently exist? One.

I get your point about the inertia of there being one de facto implementation, but that’s not quite true. For example Glib’s DBus library contains an (almost) fully featured server implementation.

Anyway I’m not all that worried about the parser in particular. For one DBus wire format is well defined and pretty straightforward. This isn’t ASN.1. Actually it’s probably way simpler than modern DNS with EDNS, DNSSEC etc.

Isn't dbus-daemon and kdbus (in a couple of incarnations) different implementations?

kdbus was a different implementation, but I was under the impression that kdbus was "only" a routing implementation (though in truth that's all that dbus-daemon is anyway). However, kdbus never landed anywhere and it has been abandoned in favour of bus1: https://www.youtube.com/watch?v=6zN0b6BfgLY.

Ahem! The DNS protocol itself qualifies as a "custom binary on-wire format" in this regard. Be careful with this argument. (-:

Good to know I am not the only one thinking this way...

>The shoggoth keep sprouting pseudopods

You're spot on.

We should just start submitting patches that more or less copy-paste the code of the current best solution to the problem over the systemd implementation.

There's a good implementation of systemd here: https://github.com/bluerise/openbsd/tree/master/sbin/init

I imagine because the people who wrote it were C programmers. Did any Ada/DNS or other $LANG/DNS people step up?

Those people step up only for objective technical criticism. Writing software systems/utilities is for others.

> Someone would ask this sooner or later, so.. why is this written in C, really?

When systemd was started, Rust barely had a working compiler and go had been announced for about one year.

Sure, but Ada was a first-class language in GCC, many distributions shipped OCaml code...

Do you think (as in bet-your-company's-profits-on-it believe) that Ada will still be a first-class language in GCC ten years from now (the standard product lifecycle for RHEL), and that you'll be able to staff the project and build a community throughout that period?

If I had to choose between betting my company's profits on Ada or C, I'd choose Ada (though I think there are better choices today). Limited tools and a need to train developers are easier to deal with than random crashes and security vulnerabilities.

But it's not "just" limited tools and a need to train developers. A language having a small community results in a lack of library and collaboration; you end up dealing with tool vendors who barely manage to keep themselves afloat, let alone invest in development, with long unmaintained libraries, with months, sometimes years passing between when a new architecture or OS is available and when the compiler and the libraries you use get updated.

It's not too different from how things are in Common Lisp land, a language (and a land...) that I'm pretty familiar with. It's a great, probably the best language. There are a few success stories, but truth is, in 2017, most large-scale, non-hobby projects are failures.

Ada, FreePascal, Oberon, ActiveOberon, ComponentPascal, Modula-3, D

All have GNU/Linux compilers available.

I love Ada, and I've written Ada code, but there are so few people who know it that building a community around an init system built in Ada is very difficult. The barrier of entry for contributions is "learn this language developed by the DoD thirty years ago that you won't use unless you work on embedded systems, in the US, for a living." I agree that it's a better technological choice than C, for any systems-level program, but Red Hat, like virtually any company out there, cares about money more than tech.

FreePascal, Oberon, ActiveOberon, are all great (I'm hesitant to say I know Oberon since I haven't written Oberon code in like 15 years), but besides having the same problem as Ada above, the communities maintaining the compilers are small and understandingly fragile. systemd is still going to be here 15 years from now. Oberon -- who knows?

Modula really belongs in a museum :-).

Besides, they'd all need things like D-Bus bindings etc., a working, stable compiler is just the first step.

Yeah, I am painful aware of the reality, being an Wirth language's fan since the early 90's.

The fact is that UNIX-like OSes are married with C, unless there is a commercial entity like Apple or Google, pushing out of the way, UNIX FOSS developers will always gravitate around it for system level applications.

It has always been like that, system languages that aren't the platform main language(s), are relegated to 2nd class status and eventually die or strive in a small niche.

Hence why I think UNIX only has a path to safety in the hands of Apple and Google, because I don't see *BSD or Linux developers using anything other than C for system level code.

It would appear none have sufficient interested developers to work on an init replacement

GNU Shepherd is an init replacement written in Guile, a dialect of Scheme. Guix ships with GNU Shepherd. Anything that runs in place of init should in principle be small, and hence not too difficult to write and maintain. So you are right that it is not any technical issues, but rather the disinterest of system software programmers in anything other than C, and the disinterest of language X programmers in system software, that is the main culprit.



Long time ago there was an attempt to build an userland in Ada, sadly they only managed to get an handful of developers.

systemd has had close to 1000 contributors now (as recorded by git), with 30-40 active per month. Higher than I imagined. https://www.openhub.net/p/systemd

I thought the piece of software under discussion was systemd-resolved. In which case-- why was it written in C?

That is not what springs to mind, more "why the fuck are you reimplementing DNS in init".

Like, this stuff was built tens of years ago and that code is crappy too but we have pretty much got rid of the most obvious security issues. Nobody wants to relive history so you can finally implement a broken DNS client.

systemd is not "just" init, it's a suite of various tools, most of which (including systemd-resolved) don't run as PID 1. It's a monolith by the fact that this project decided to take over a variety of normal system daemons and make it as difficult as possible to use many of them without using the rest - it's not a monolith in the sense of everything running in the same process.

I believe systemd-resolved, however, is one of those components that is entirely optional, and which nothing explicitly depends on... which makes it weird that Ubuntu chose to use it by default.

Ubuntu already had a resolver installed by default on desktops (dnsmasq). They decided to switch because:

we picked "resolved" as that is small and lightweight, already present (part of the systemd package), does not require D-Bus (unlike dnsmasq), supports DNSSEC, provides transparent fallback to contacting the real DNS servers directly (in case anything goes wrong with the local resolver), and avoids the first issue above that /etc/resolv.conf always shows

DNSSEC is dead and useless unless every application is written to understand the error messages and every device runs its own DNS resolver (not forwarding, because it's not really validating then and the responses could be spoofed).

We don't need DNSSEC because it doesn't solve any existing problems. The validation is done at the application protocol level with TLS, and apps that aren't running TLS need to fix this gap.

So as it turns out DNSCrypt is winning the internet even though the standards bodies blocked it. Additionally, OpenDNS has massive deployment of DNSCrypt users and this is being furthered by Cisco Umbrella. Cisco is adding this capability to iPhones now as announced earlier this week.

tl;dr DNSSEC has always been DOA, but DNSCrypt is just getting started.

The one and only application I knew of that added DNSSEC for DANE removed it because it was worthless (irssi, irc client).

dnsmasq doesn't require dbus though: that's an optional dependency that has to be enabled at compile time.

To make it work with Network Manager, it needs DBus support. So distributions compile it with DBus support.

So eliminate Network Mangler, two problems with one stone...

Sure, but the key there is NetworkManager. dnsmasq itself doesn't require DBus.

How does systemd-resolved work with NM? If the goal in general is to have a non-dbus version when NM isn't used, then provide both versions as packages.

Are you confusing "can use" with "requires"?

I suspect any alternative is a fall back that cause as much troubles as it "solves". After all, the principle devs of systemd are all very much in love with dbus (bloody thing require a copy to be started by initramfs even).

You are missing the part where the user manual and the systemd new features announcement state that the Desktop Bus API is systemd-resolved's "native, fully-featured API"; and describe the GNU C library NSS API and the DNS APIs as limited functionality APIs, whose avoidance by applications is "strongly recommended" in the case of the latter.

Indeed. It's not just init, it's Windows service manager, COM, MSMQ, task scheduler and event log and all the associated problems in one convenient package for Linux!

Not just that, but it's both a floor polish and a dessert topping!

> I believe systemd-resolved, however, is one of those components that is entirely optional, and which nothing explicitly depends on...

Yet. Wouldn't be the first time some "optional" component became mandatory.

Which optional systemd components became mandatory?


When was journald optional?

When systemd first landed in Fedora 16.

You could use syslog or journald (or both. But journald was optional)

Journald didn't even exist when Fedora 16 was released, so how could it be optional?

Meanwhile, from the first public document of journald[1], it was always designed as an indispensable component of systemd.

[1] https://docs.google.com/document/pub?id=1IC9yOXj7j6cdLLxWEBA...

I have strong memories of installing it on fedora 16 long before the 17 release was announced. I don't know about intent but I was a very avid fedora user and I was pro-journald before it was forced down my throat.

> "why the fuck are you reimplementing DNS in init"

Because systemd

How plausible is it that someone/some group could rewrite/update this to be written in Rust? (Which would presumably solve a lot of the memory corruption issues if I understand Rust's memory safety correctly?).

Whats what Redox is, pretty much. The trick to understand in the GNU/Linux world is that C is sacred - it is so sacred Gnome developers write desktop applications in C. It is absolutely a religion.

A lot of it is legacy, of course. The steering heads of projects have been around for over 30 years in many cases. These are people who dedicate their lives to a cause, and a lot of it is relation to a vision of the perfect OS circa 1990 - albeit, systemd doesn't follow that philosophy, but the participants in the project are cut from the same cloth, with some new blood and ideas mixed in enough to cast aside the unix philosophy but not enough to change course away from C.

And its all free software, after all. The developers of coreutils, Linux, Mesa, GCC, systemd, NetworkManager, Samba, NFS, and so many other services and applications in use by millions all at least started out as a project of passion. They chose C because that is where their passion lay. We are seeing a new age of such passions emerging around Rust, which is great to see. Whether or not Redox or similar projects can develop the momentum to approach the C lineage is something to be seen (and I would add the permissive licensing is not helping their situation) but the spark is definitely there.

Rust has an important advantage over many other languages: since Firefox now requires it, for most desktop distributions it becomes one of the "must have" languages, together with C and C++. That makes writing system software in Rust an easier sell. Also, IMO Rust sits between C and C++ in the programming language spectrum, so it should be more acceptable for C and C++ programmers than higher-level languages.

Rust isn't one of those languages you need to include in a distro. Binary rust is just so's and elf's. It has no runtime, so its compile once and run anywhere with a C linker.

Its development tools are spread like wildfire, but in part that is because of their isolation - you only need rustup to bootstrap your own local Rust ecosystem.

Compared to many other recent native languages, the lack of a runtime absolutely helps Rust in adoption.

Actually it was the adoption of GNU/Linux and *BSD that increased the adoption of C, given that they are UNIX systems.

Back when GNU/Linux was still at 0.x versions, the OS industry was starting to move to C++. Even though Mac OS, OS/2 and Windows APIs and kernel were written in C, everyone was using C++ with PowerPlant, OWL, MFC, CSet++ or languages like Object Pascal.

OS like Symbian and BeOS were even fully written in C++.

But the adoption of GNU/LInux and BSD with the sacred C, meant everyone that wanted to play ball need to use C instead, so the adoption grew and here we are.

Not plausible at all.

    * Rewriting a codebase is much harder than it seems
    * systemd is pretty big (376,726 LOC according to Open Hub) which makes it even harder to rewrite
    * All maintainers and contributors are C programmers
    * Distros don't want their codebase to be made up of many different languages

* You can just rewrite systemd-resolved (and similar networked services), not the entire systemd, for a start. E.g. Firefox, which has even more LOC, started rewriting a ton of stuff in javascript and now rust (e.g. mp4 parsers was the first rust code in Firefox IIRC)

* If your project lacks people with the required skill set, then reach out to programmers who got what you need and educate yourself.

* Distro codebases are not just C since forever, they are a mix of all kinds of stuff, in particular but not limited to C, C++, perl, shell, python.

> Distro codebases are not just C since forever, they are a mix of all kinds of stuff

Indeed....I was surprised to discover OCaml used in Citrix XenServer when spelunking the codebase.

  > * Rewriting a codebase is much harder than it seems
… which is why systemd shouldn't be doing it.

> * Distros don't want their codebase to be made up of many different languages

That ship sailed a long time ago. Distros already contain C/C++/Python/Perl/Shell Script and others. It is meaningless if you added Go/Rust to that mix.

> systemd is pretty big (376,726 LOC according to Open Hub) which makes it even harder to rewrite

That's about twice as much as the Linux kernel when I started using a Linux distribution, I believe...

Please, Linux 1.0 was 150k loc, it's in the millions nowadays

That seems unlikely.

However, I noticed Bruce Perens' message on the Devuan list about the idea of providing a libsystemd0 interface that calls non-systemd services to complete the requests that come in to the systemd API:


The plumbing for something like that could indeed be written in Rust. :)

edit: typo

Rewriting in C++ would be a better and more practical choice though. Mostly because you can rewrite one component at a time.

Same can be asked about Linux, the kernel.

Linux was written in 1991. Systemd was started in 2010.

The further you go back in time the less relevant the question is. And arguably any projects in the future written in C instead of a safer language really need to justify that choice if they sit on a security boundary.

C will be around for another hundred years or more. But hopefully new software looks beyond C giving that programmers seemingly cannot write and maintain secure software in it.

> The further you go back in time the less relevant the question is.

As Hoare so elegantly described at his Turing award speech, regarding Algol compilers, done in 1981:

"Many years later we asked our customers whether they wished us to provide an option to switch off these checks in the interests of efficiency on production runs. Unanimously, they urged us not to--they already knew how frequently subscript errors occur on production runs where failure to detect them could be disastrous. I note with fear and horror that even in 1980, language designers and users have not learned this lesson. In any respectable branch of engineering, failure to observe such elementary precautions would have long been against the law."

Algol dialects like ESPOL and its successor NEWP where used for systems programming the Burroughs B5500 in 1961, 10 years before C was born, nowadays still sold by Unisys as ClearPath MCP.

Well, I guess, this has got to be said: security should never be a concern for application software developers.

This may or may not apply to things like systemd which live somewhere on the boundary between what would be pure "system" and "application" programs, but it is undeniably true that application program code, such as that of a document editor or a calculator, should be solely concerned with the application side of things, i.e. correctness and efficient implementation of what is otherwise known as "business logic", and security is usually not one of them - contrary to a very common, but mistaken, perception. It is the "system" component of the execution environment that should focus on what it has been designed for in the first place.

Therefore, ideally, it should not matter what programming language is used to write application software - whether it is C, Rust, Prolog, or SQL; it does sound ironic, though, that the most demanding pieces of a system - demanding in terms of reliability and security - are usually written in an "unsafe" language.

If that comparison do not get people going "wait, what?!", i don't know what will...

In a word? Arrogance. LOC in c required to create systemd and all of its unnecessary processes is astounding.

Because proper, hardcore programmers never make memory management mistakes and memory management is not that big of a problem, obviously. /s


Indeed. Merely "loud" programmers with corporate backing.

Debian without SystemD


It only affect ubuntu's way of systemd that is discouraged by systemd's community

Some one called a title another systemd's vulnerability a click biat


Try to guess what title catches more clicks: 1. CVE-2017-9445: systemd Hit By New Security Vulnerability 2. CVE-2017-9445: systemd-resolved, which is not recommended on most systems and isn't used outside of Ubuntu Hit By New Security Vulnerability

16.04 is not affected

I bet init is also unaffected.

14.04 used upstart (also used by chromeos). sysvinit was used in ubuntu prior to upstart, and there are some distros that use bsd style init. Go read up on init system options a bit more.

yes, i'm aware of bsd init, sysvinit, upstart, systemd et al.

systemd & upstartd all aim to replace pid 1/init. Which as far as i'm concerned anything beyond bsd init is over complicating things, and these are the results.

Looks like you need to make a DNS request to a malicious server to be vulnerable. This means you are safe if you are using Or another trusted network? (Or your ISP if you trust they haven't been compromised).

The real danger is a script kiddie on your LAN with a sniffer or some advanced attacker in the position to MITM you on the wide Internet, depending on whether you are a small fish or a big fish.

US corporations control the root name servers and seem to have no problem cooperating with government requests to fuck^H^H^H^Hkeep a close eye on everyone else.

K root is operated by RIPE NCC M root is opreated by WIDE from Japan


Use DNSSEC, it's pretty tamper proof, keys are in HSM and "geo distributed" ( https://www.schneier.com/blog/archives/2010/07/dnssec_root_k... ), the weak points are probably the facilities themselves in the US (one on the East Coast and one on the West Coast), but the trust anchor is pretty much fixed in the root servers, and it'd be quickly discovered if someone rolled a new one out of schedule.

DNSSEC does absolutely nothing to resolve the problem the parent commenter is referring to. In fact, DNSSEC cryptographically ratifies the status quo of the most important TLDs being de-facto controlled by Five Eyes governments.

In years of watching for mentions of DNSSEC on HN, I can't remember off the top of my head a single case in which DNSSEC was introduced into a conversation as having some benefit where that benefit was real. It's weird what people believe about DNSSEC.

Please elaborate.

Parent seems worried about the root servers serving malicious responses for any given domain. (While assuming all root servers are under US control.)

In case of a non-US controlled TLD (.ru, .cn, .de, .eu) why DNSSEC is worthless?

Debian without systemd: https://devuan.org/

Does this affect computers that did not ask for such packet (dns response)?

It's extremely easy to induce a computer to make a DNS request. For example, embed an IMG tag in a web page pointing to the attacker's domain. Anyone loading that page will get the malicious DNS response.

DNS is UDP so you might just get a broken packet sent to you, I guess?

Only if daemon is listening to the outside, which I hope is not the case by default.

TCP or UDP transports.

The title is slightly misleading since it is specifically the optional (but installed by default on Ubuntu) systemd-resolved package (an ancillary package under the systemd name), not systemd the init system as I think many people will assume.

Edit: It seems Ubuntu builds it together with systemd so users have no choice. There may be a good technical reason for this, but I'm not sure what it is because it seems very user-hostile to remove choice like this.

Edit2: Upon further inspection this appears to be common practice, you just don't enable the parts you don't want. It would be nice if they could be put into separate packages or something of that nature though.

I don't exactly know why it's in the same package as systemd, but why do you consider it an user-hostile decision?

Unless you have so little storage you can't afford to have an extra binary installed in the system, there is no downside of having it on the machine.

You can still disable the daemon and switch to another one (like dnsmasq), as if it was in a different package.

Technically it's not a huge problem; politically, bundling unrelated software together means that the bundled software has an advantage and a tendency to get more market share than its competitors who compete fairly. In the case of open source distros, I'm sure that this isn't illegal, but it seems like it isn't in the interests of the community.

Well, it's clear it doesn't compete fairly with the other daemons, because it's the default one since Ubuntu 16.10 [1]. So, bundling it with the systemd package doesn't harm anybody, because you'd have to install another package anyway to change the default.

[1] https://lists.ubuntu.com/archives/ubuntu-devel/2016-May/0393...

cough Windows cough Internet Explorer cough

It's not as user-hostile as I originally assumed (I thought it was built and enabled with no option to turn it off). As long as it can be completely disabled so that nothing will ever touch it, then it's fine. And that does indeed appear to be the case here.

Regardless, I'm sure there are some people who would love to claim a few KiB back without having to compile things for themselves.

Maybe not in this case, but this is not generally true. A installed executable could increase the attack surface, for example if it has setuid set and a exploitable bug is found.

"Rewrite It In Rust" should be the default, pre-set comment to every article about every vulnerability

Well no not really. Vulnerabilities exist outside the realms of the language implementations. There are poorly designed protocols and access controls to contend with as well. I'd argue there are a lot more of those classes of problems out there. The ones enabled by programming languages are merely easier to find as you don't have to understand the precise problem domain of the application for each one found.

Maybe every memory access related one. I assume rust still allows you to pass untrusted user input around, for example.

Oh yeah. Cross site scripting and SQL injections are still perfectly easy to write in Rust. You can accept a web POST and pass it directly, unquoted, to a local shell too.

Rust solves every vulnerability ever made

Using a safe language would help even more. Safer than C != Safe.

Who could have predicted that bloating PID 1 process could result in funny CVEs like this!

systemd-resolved is a separated binary of the systemd project, not the PID 1...

systemd-resolved is a separate process (not PID 1) that just was written by the same authors as systemd-the-pid-1.

Maybe there would be less confusion if they changed the name to something not including systemd, and decoupled the development and distribution of these clearly unrelated projects.

Then this DNS resolver could get the distribution and usage it deserves based on its own merits.

Of course, that's not going to happen, because the creators want systemd to be an OS by itself, with every buggy unreliable component standing as a monument to them only, and that means strong-arming in projects that could never compete with the existing working solutions on merits.

Effectively Freedesktop has given up on defining the Linux desktop by specification, and have switched to do so by canonical (heh) implementations.

And maintained within the same tree so that they can change interface details between the "independent" parts at a whim.

In contrast i can pass data between GNU core utils, BSD equivalent, busybox, toybox, and expect things to work. Because the way they communicate is documented and stable.

That is between systemd as a whole and third party code, not between components of systemd (systemd-init, logind, resolved, etc etc etc).

In contrast i can mix ls from GNU, grep from BSD, etc, just fine.

Applications are open for YC Winter 2022

Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact