Ubuntu Systemd Vulnerability
ubuntu.com
ubuntu.com
> 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.
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" ?
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)
Security
.. sudo vs Polkit
etc.
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.
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.
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.
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.
> 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.
See also:
https://www.freedesktop.org/software/systemd/man/systemd-res...
LLMNR and per-interface DNS resolution are features that very few applications need. Those that do can link with their own resolver libraries.
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.
And Ubuntu used dnsmasq as a caching resolver for quite a long time. (Via using 127.0.0.1 in /etc/resolv.conf)
systemd-resolved is sort of the same thing (and it listens on 127.0.0.53, 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.
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:
https://www.freedesktop.org/software/systemd/man/nss-resolve...
I'm not responsible for any harm to systemd resulting from the use of this information ;)
edit:
And yes, the current version of the package is 232, built in January, so should be vulnerable.
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.
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.
The versions provided by most cloud hosters are also misconfigured to listen on all interfaces.
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.
You get on some distros by default something that that makes you subject to DNS amplification attacks.
I believe there is a built-in solution in glibc:
http://prefetch.net/blog/index.php/2011/03/27/configuring-ns...
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 recently (2016) built a little network appliance for a specific task that needed to be safe and secure.
I used FreeBSD 4.11.
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.
Jessie is not vulnerable.
Stretch is vulnerable (no patch yet), but systemd-resolved is not enabled by default.
I'm sick of Linux Servers I use, being "improved" with Desktop implementation in mind.
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.
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.
The whole of systemd is a comedic fuck you to POSIX and the mentality of a system which is standardised.
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.
http://www.cs.columbia.edu/~vatlidak/resources/POSIXmagazine...
https://www.usenix.org/publications/login/fall2016/atlidakis
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.
Stardards are only relevant as long as the industry cares to use them.
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.
Not everyone wants to live in the past.
Not sure how you could even think that people need Red Hats finances to create something in linux that actually functions, and is worthwhile.
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'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.
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.
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 :)
Then I think you'll love Slackware!
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?).
I'm not saying it is planned, but i wonder if there is a echo chamber effect going on...
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).
* https://jdebp.eu/FGA/systemd-documentation-errata.html#Contr...
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.
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 %
systemd is not the sole user of version 2 control groups.
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.
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.
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...
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.
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.
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.
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.
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.
Someone would ask this sooner or later, so.. why is this written in C, really?
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.
Because systemd
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.
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 127.0.0.1.
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).
Yet. Wouldn't be the first time some "optional" component became mandatory.
You could use syslog or journald (or both. But journald was 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...
* 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* 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.
Indeed....I was surprised to discover OCaml used in Citrix XenServer when spelunking the codebase.
That's about twice as much as the Linux kernel when I started using a Linux distribution, I believe...
> * Rewriting a codebase is much harder than it seems
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.
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.
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.
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.
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:
https://lists.dyne.org/lurker/message/20170618.121634.7c0d5b...
The plumbing for something like that could indeed be written in Rust. :)
edit: typo
When systemd was started, Rust barely had a working compiler and go had been announced for about one year.
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.
All have GNU/Linux compilers available.
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.
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.
The shoggoth keep sprouting pseudopods as devs gets bored and think they can reimplement a time tested daemon in a weekend.
You're spot on.
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).
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.
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.
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.
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.
"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"
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.
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.
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.
Some one called a title another systemd's vulnerability a click biat
Quote
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
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.
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.
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.
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?
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.
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.
Regardless, I'm sure there are some people who would love to claim a few KiB back without having to compile things for themselves.
[1] https://lists.ubuntu.com/archives/ubuntu-devel/2016-May/0393...
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.
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.
In contrast i can mix ls from GNU, grep from BSD, etc, just fine.