Are there significant security issues with the new "systemd init" system?
 

I was completely unaware that this was going on because I usually don't mess with init, but apparently it's been a major fight for the past two years that I can't make heads or tails of.

I've heard a lot of arguments against it, but most distributions seem to be adopting it. The arguments are kind of a mess, though, and I can't figure out whether it's a security risk or not.

Most of what I'm reading is about it trying to take on too much work for an init system. Monolithic design has some disadvantages, but that's not really what scares me.

I've been hearing about stuff like systemd reducing overall security because it includes an http server, runs at PID 1 which gives it special permissions, and potentially opens up backdoors to everyone from hackers to the NSA.

So, are the security concerns realistic? I always thought Linux was supposed to be more secure than Windows (I always try to handle my sensitive data on Linux variants), and I don't get why distributions would be adopting something that puts users at risk just to ensure compatibility with GNOME (which is a really ugly desktop with a bad UI anyway). I'm pretty confused about all of this.

While I don't want to start a flame war, again, here's why I don't use it and never will:

Feature creep - I am not sure if it's an init system anymore.
Developers attitude.
Poor design solutions.
Too much buggy code.
Lack of portability.
Inability to remove it, if your distribution uses it by default.
Inability to compile against other standard libraries (not glibc), notably musl.
D-Bus is used for communication.

PID1, to me, should boot, reboot, shutdown. The amount of code and features is increasing dramatically, and sometimes developers try to reinvent the wheel (notably sudo). And it looks like we all should use it and don't question it.

Speaking of security, issues may appear (or already are) there, because of feature creep, too much code and poor design. So, if you have a choice (luckily, you still do) I would recommend not using it and avoiding. systemd advocates are, most of the time, desktop users with GNOME, not sysadmins, "neckbeards" or old-school hackers.

Remember, this is biased. However, be careful when asking about/questioning systemd: you will probably be claimed as troll by its supporters and, moreover, blocked by forum mods (not on this forum though).

Just my $0.02

Everyone knows systemd was created by Satanists due to an Obamacare mandate that was required to help cover up what *really* happened in Roswell New Mexico. The source code has comments by Lee Harvey Oswald, Ted Kazcynsky and Haman so you know it can't be good for you. :rolleyes:

As you said it is being adopted by most of the large distros. Some people argue against any innovation not because it is bad but because "the old way always worked". Systemd is not in and of itself insecure. Systemd systems just like Init based systems can be insecure if security mechanisms aren't adhered to.

There is no guarantee that httpd or any other process will be PID 1 because things start asynchronously so any given process might actually grab a PID before another. This isn't an issue because init at PID 1 does NOT underlie all processes as it did in init based systems.

I'd say the main realistic security problem is that it is a large actively developed and new project. Like all such, it is likely that errors will creep in which open security holes, which get discovered and are repaired. Maybe "problem" isn't the correct word to describe that situation. Systemd seems to have enough critics looking for problems, so I doubt anything major will be missed for long.

Hi,

Couldnt help noticing.

I read in one of the LQ posts that systemd is good for server farms.

Then why does ubuntu have it in its desktop version ?

I do have the answer to that one. It's because some software packages have decided to make systemd a requirement, the biggest one is GNOME. And I know that Ubuntu uses Unity, which I believe is based on and requires GNOME. I think that's what pushed most distributions over the edge, but I'm not certain.

Personally, I doubt that too much more can be accomplished by these conversations. :)

systemd is obviously a design that is trying to consolidate many functions that were previously handled by several "legacy" daemons that didn't know about one another and that do not talk to each other. It is obviously designed with "we have hundreds and hundreds of rack-mounted servers" in mind. (And, more generally, "clustered computing.")

It will have the same inherent flaws and holes as any complex, actively-developed project would naturally have.

Personally, I just wish that the damned thing were more modular. You don't get to choose whether-or-not you want a kitchen sink.

Well, I did some more research. Actually found a blog post by the guy who created it. The gist I'm getting is that he's your typical German that's into efficiency and control, and that's the philosophy the software is built around. Doing everything as efficiently as possible with whatever is available. This doesn't mesh too well with the (arguably very American) Linux philosophy of modularity and freedom of choice.

But he doesn't really seem to be a bad guy at all, at least as a person... I've met software developers that are extremely rude to everyone for no reason, and who never wanted to explain their reasoning for anything.

The more I look into it, the more I'm getting the impression that the biggest problem with this software is that it goes against the grain of Linux.

For instance, I can choose between GRUB2 and LILO, and sometimes other boot managers as well. So, if I don't like GRUB or the developers rub me the wrong way, I can use LILO instead, even if it isn't as functional in some scenarios. You have that choice. If I don't like Emacs, I can use Vim. If I don't like GNOME, I can use KDE. Don't like GTK? There's always Motif or Qt. Even with GUIs, you get your pick between Xorg, Wayland, and SVGALib.

The biggest problem with systemd seems to be that it just... doesn't allow for things to work this way, and so many things have their "hooks" into the system at a level that makes it difficult to patch it out. So even if you don't like systemd, it incorporates so many low-level processes that it will become increasingly difficult to avoid it... because all it takes is one essential application using a new feature of something like udev or the logind system, and you're stuck. It's almost like an extension of the kernel or glibc, which up to now were the only components of the system you were generally "stuck" with. Sure, you could use something like an alternative libc, but a lot of stuff depends on glibc-specific features to the point that it's not practical.

On the other hand, systemd gives you quite a bit in exchange, especially if you're a mobile user that's always changing your configuration. It improves boot times, makes the system more adaptable, etc.

I can't find much information about specific security flaws in it, though. The culture shock seems to be a bigger issue for the people who are most strongly against it, and the potential security issues are always a sidebar in discussions that center on people disliking the centralized control and lack of choice.

I definitely would have preferred to see a criticism of systemd that centers on the security flaws and exploits it opens up, because I haven't seen a lot of concrete examples.

As it is, I kind of see both sides and feel more unsure of which way is right the more I research it. It looks like that's probably why it's so controversial, is because there is no one right way to look at it, so people end up looking at it from different perspectives and coming to different conclusions about it.

I have a friend who is sysadmin of RHEL network. His statement on SystemD is that it works more smoothly than SysV, but, if something malfunctions, it can be more complex to find the trouble and shoot it.

I have a computer running Mageia; Mageia has had SystemD for several years. I've had no init problems with that machine. Personally, I prefer Slackware's BSD-style init scripts, because they are easier to understand--everything is plain text--and I understand them after 11 years of using Slackware.

Personally, I think much of the opposition to SystemD is based on inertia, which is one of the most powerful forces in human behavior.

Some of it is philosophical: SystemD is monolithic and counter to the traditional *nix philosophy that a program should do one thing and do it well; SystemD does many things, but, irritatingly, does them well.

Some persons think that Red Hat is plotting to take over Linux and SystemD is part of their grand strategy. I do not find that at all credible. Red Hat wants to sell RHEL. It does participate positively in the open source community and has a history of not being nefarious. (In fact, I think MensaWater should have included that in his first paragraph, along with the other conspiracy theories.)

However, the technical reasons for opposing SystemD are few. It works, and distros are adopting it because it works.

I don't know which is the right way but the good news is that there is no wrong way... Security flaws are normal for a project of this scale and SystemD didn't had a large numeber of them and didn't have severe ones not being dealt with in promptly so don't actually belive people that tell you it's a security concern (also, the infamous PID 1 is used only for the bare minimum)... So the lesson here is don't listen to non-arguments and subjective opinions... Speaking of which, here's my completely subjective opinion on the matter:

SystemD was an effort to create a faster boot "program" with ".ini" configs.. That was it... After that was achived instead of the author taking the time to actually clean, test and optimize it's code, he (they) begun to extend it and for some reason and implement (or reinvent) features (albeit, some of them are very nice ones, "logind" is probably something that Linux OSes needed for a long time) in itself, not as a separate library and keeping the code so tangled up that the libraries couldn't be really separated and depended on the core (which kind of makes it monolithic -- which is something it's authors keep denying for some reason)... People just have the felling that developers who want to take advantage of a feature of SystemD (which they should) are obliged to write separate code for non-systemd systems and vice-versa... And the truth is that an init system should by no means be a dependency of a program/application, no matter how complex, if that program is not an actual extension for that init system... So here, that's why I'm against it...

But to tell you the truth, as end user/power user, systemd will usually feel more easy, more familiar and will make more sense.. It's kind of why it has this level of succes.. As a developer it's also easy to use what the system provides.. Porting is not an issue because quite frankly the writers don't want to port it.. And that's fine (yes, it really is -- go port it yourself if you don't like it)... But as an init (which is the primary job and goal of the project) it fails horibly in my opinion imposing both dependencies and being an imposed dependency for stuff that usually don't have anything to do with booting and getting the system up and running. I'm not a fan of conspiracies but I'm pretty sure this was intended and that's what scares me.
Here's a pragmatic discussion I like... Do you see how an init change proposal was quickly changed in what should/could be done afterwords with X, then maybe Wayland, etc.. The proposal was full of aparent advantages and selling pitches yet it hit two pragmatic responses: (a) there needs to be a clear advantage, and (b) X, Wayland, the login manager, etc "it's quite unrelated to initsystem, and certainly not a rationale for switching". Unfortunatly that's the sum of SystemD.. Full of aparent advantages and selling pitches when in reality it's just a complex set of programs and libraries that wants to act as a framework to every god damn thing and is developed by people who simply lie to everyones faces (1. it's monotlithic by every definition; 2. Speed is one of the things guy writing that started the project, etc)...

//End of subjective opinion..

Forget the crazy software.
Ask WHO financed the development.
The same people that would gain financially if Linux and all forms of it failed.
Who payed retainers to crazy software makers of systemd and the other questionable software, the same people ?
Who payed SCO to keep attacking Linux or Unix, the same people.
Conspiracy theory maybe !
Facts True !

The OP is asking for any security problems with Systemd. So please (all) keep this thread on topic. If you must inject Fear and Doubt, if you can't contain yourself and spout subjective opinions: there's the slackware and general forums for ya. Capice?

Aye, and let us ever be mindful that there are "necessarily, implicit(!)" loaded questions in the OP's thesis statement: "Are there [...] 'security issues with' ... 'the new' ...?"

The short-answer, very obviously, must be: "yes!"

Anytime you replace something ... "aye, with anything at all, and in any context at all" ... there will be: 'issues.'

The operative question, then, might well be: "to what, and(!) whom(!!) should you assign 'the blame?'"

... and possibly the best-all-around answer to that question just might be: "don't try to 'assign blame,' at all." Because both scenarios ... "before," and "after" ... have "blame."

It's just the way of things.

"Therefore, just [shaddup and ...] fix the damned things!" :)

---
("You fool!!" Do you actually want to wake-up the c-u-s-t-o-m-e-r-s?! Can't you see that they're all still comfortably asleep? Don't you want to KEEP them that way?!) ;)

Perhaps the way I phrased my question wasn't perfect.

So, everything I've managed to put together suggests that the main vulnerability that keeps coming up with systemd is actually something related to DBus communication. And from what I'm seeing, it was a much bigger issue two years ago than it is today.

Does that mean that as long as DBus is relatively secure, systemd is relatively secure? That's the impression I'm getting now.

Not the way, but the question itself. As I said, if you question something about systemd, the war starts again.

D-Bus is vulnerable, by design and by code itself. It's slow, poorly written and has (seriously) no purpose, apart from additionally cluttering the system. It uses Unix sockets for low-level communication, thus it's another try to reinvent the wheel. Ironically, it's developed by the same Red Hat and promoted by the same freedesktop.org. And, again, if you have a chance, avoid using it.