Re: [Shorewall-users] SystemD (Was: Transparent Firewall: pros and cons)

[Simon <li...@th...>]

Thomas Schneider <74c...@gm...> wrote:

> With regards to Debian installation on Alix board I didn't consider that there's a downside of systemd.
> In fact I found a webpage that documents the installation of Debian Buster on an Alix board.
> What is the downside using systemd on an Alix board?

OK, this is heading into “vi vs emacs” or “likes or doesn’t like Marmite" flamewar territory, but my thoughts on SystemD are along the lines of :
It’s a huge lump of intertwined code, which while it may be in “modules” and so they counterclaim that it’s modular - there’s no stable or even documented API so there’s no option to swap out any module you don’t like with anything else.
It’s written by people with a track record of poor quality code - and Linus publically flamed one of them for breaking stuff yet again https://www.theregister.com/2014/04/05/torvalds_sievers_dust_up/.
Their attitude to compatibility with anything not written by them is “it’s up to others to fix anything that doesn’t work when we’ve changed stuff”
Their attitude to existing stuff is “we’ll replace i... because we want to”. In the case of time sync - they have replaced ntpd (that does it properly, well, and is mature) with their own attempt which does it wrong (it steps the kernel clock rather than drifting it into sync) and uses SNTP which is less precise. So replacing a tried and tested, does one thing and does it well, piece of code with something worse and less precise. As well as NTP, DNS and Syslog come to mind as stuff they “decided didn’t work as they say it has to”.
It obfuscates stuff. With SysVInit, you can hack your shell script control files if you need to debug something - with SystemD, it’s mostly obfuscated into a chunk of C that interprets a unit file and does (hopefully) what you want when starting a service. And they’ve declared text log files as “a problem” and gone with binary log files that can only be interpreted with their programs - so if a log file gets corrupted, you can’t look through it’s remains to pick out clues, the log file query tools will just barf on a corrupt file. Again, there is some disingenuous language used as they will tell you that you can still send stuff to log files - but only when their logging system is up and running which (in the case of startup issues) may be too late to catch what you are looking for.

And for the main reason ...

PID1 is, after the kernel itself, **THE** most important piece of code on your system - if it falls over then your system falls over, it has higher privileges than root and if it has security issues and gets compromised your system is compromised. Basically you want PID1 to small, tight, well written and present the smallest attack surface possible to harm.
All other PID1, a.k.a. inits, are small standalone pieces of code with well defined APIs. SystemD replaces this with a large furball (significantly higher attack surface) of code that’s already had several significant security issues.


And from the PoV of running on small systems, it removes a lot of choice in terms of what code you run on the system. Just to make SystemD work at all, you will need quite a lot of stuff that you probably don’t actually need and/or there are smaller alternatives for.


Simon

And for a bit of a laugh, see https://www.theregister.com/2017/07/28/black_hat_pwnie_awards/, scroll down to "lamest vendor response” …