35 ms·

Yeah, that's to put it mildly. This gem is right up there in the first page: Use a distribution with an init system other than systemd. systemd contains a

Yeah, that's to put it mildly. This gem is right up there in the first page: Use a distribution with an init system other than systemd. systemd contains a lot of unnecessary attack surface; it attempts to do far more things than necessary and goes beyond what an init system should do. An init system should not need many lines of code to function properly. Wow! To put such a controversial feature, and present it as "this is the truth, just how it is", without even mentioning that it's just an opinion and a lot of people have a completely opposite one, and both for good reasons. That just makes me distrust this guide because it is so opinionated and subjective.

sliken 6y ago
Systemd is a security nightmare, a huge amount of code, taking over various network services ... poorly. Doesn't seem controversial at all to me. Gives me the heebie jeebies to think of systemd talking to the network before I even have the client firewall up. Generally if security is your top priority I'd disable as much of systemd as possible. Things like find a good local resolver (like unbound) and disable systemd's implementation, etc.
- tinco 6y ago
  I'd like to read a guide on hardening systemd. Systemd is really convenient and I hadn't realized it poses a large attack surface. A good list with possible attack vectors and how to mitigate them would be epic. Is it really an established idea in the security community that systemd is a security nightmare?
  - tarruda 6y ago
    > Is it really an established idea in the security community that systemd is a security nightmare? Here's a list of systemd-specific CVEs over the years: https://www.cvedetails.com/product/38088/Freedesktop-Systemd.html?vendor_id=7971 https://www.cvedetails.com/product/38088/Freedesktop-Systemd... Note that these apply to all programs in systemd distribution (not sure how many of these are specific to systemd init program). It seems that a lot of criticism is due systemd doing more than a classic init process does, but some of it seem unjustified since you it is not an "all or nothing" package. For example, this specific CVE affected systemd-resolved (systemd's DNS daemon), but IIRC Debian was not affected since it did not use systemd-resolved by default: https://www.cvedetails.com/cve/CVE-2017-15908/ https://www.cvedetails.com/cve/CVE-2017-15908/ So it is perfectly fine for a distribution use systemd init system but use other network daemons.
    - Karunamon 6y ago
      >>It seems that a lot of criticism is due systemd doing more than a classic init process does, but some of it seem unjustified since you it is not an "all or nothing" package. I hate this argument because, in practice, it is an "all-or-nothing" package from a user standpoint. Packages have a terrible habit of setting dependencies on one or two of the "modules," which wind up bringing the whole thing along with them. Sure, you can "disable" it after the fact, but then you're left with a system that will break in fun and exciting ways when something a package you requested wants isn't available. If you don't want systemd, your only option at this point is also-ran distros.
      - Spivak 6y ago
        systemd is extremely modular if you’re the one compiling it (i.e. you’re a distro-builder) but not as an end-user since it’s used as the plumbing for your distro. And since distros aren’t usually in the business of telling users not to use features they ship everything because someone might want it.
    - zorked 6y ago
      The fact that systemd bundles a lot of functionality (which is different from being a monolith) means it has a disadvantage in the terrible metric of "CVE counts". Now if only the systemd-hating crowd would take a look at how many CVEs affected their DHCP client, nscd, nss and other resolvers, various PAM modules, syslog/klogd, ad-hoc init scripts writing insecurely to /tmp, ntpd, etc.
  - Foxboron 6y ago
    >Is it really an established idea in the security community that systemd is a security nightmare? It's not. The presence of CVEs in software is a sign of maturity, not insecurity. It's frustrating to see people use CVE numbers to point at some larger problem. The key element is to realize that security issues are just bugs, especially in the context of C software. What you should be cautious about is upstreams that doesn't handle security issues well. Systemd is not one of these upstreams.
    - bee_rider 6y ago
      No way man, I'd much rather use this other tossed together init system that sombody started as a pet project. No CVEs!
    - qwantim1 6y ago
      By that reasoning, Flash would be safe enough to stay around, seeing how many CVEs it had (1078 since the first CVE for it was published Dec 31, 2005). It’ll be gone tomorrow though, or January 12, or later in 2021.
      - Foxboron 6y ago
        I don't think flash proves anything. It's an extreme example after all.
        qwantim1 6y ago
        How would you modify your argument rather than dismiss the evidence against it? For example, could you propose an equation using the number of CVEs and their severity along with the the rough number of known users, showing that some curve or values would indicate maturity rather than risk? Some data for Flash[1] CVEs are available at CVE Details. Possibly you could find other products you consider safe and see how they compare. I’d be curious if an analysis would show correlation of what you’d consider greater risk with a year that Adobe started outsourcing to a particular company or decided to EOL it; I’m not proposing that quality went down due to one of those things or that they outsourced, but analyzing the data could be useful. [1]- https://www.cvedetails.com/vulnerability-list/vendor_id-53/product_id-6761/Adobe-Flash-Player.html https://www.cvedetails.com/vulnerability-list/vendor_id-53/p...
  - aorth 6y ago
    > I'd like to read a guide on hardening systemd. Here is a great guide detailing some of the security features available to systemd units from earlier this year (2020): https://www.ctrl.blog/entry/systemd-service-hardening.html https://www.ctrl.blog/entry/systemd-service-hardening.html
  - kd913 6y ago
    Systemd by itself comes with this wonderful analysis tool. Systemd-analyze security Systemd-analzye security <service> There it details what capabilities, and restrictions are in place for a given systemd service. From there you can edit the service to restrict even further as required if you want.
- uncledave 6y ago
  Completely agree with this. One of the biggest risks is using journald if you ask me. It makes logs fairly impenetrable if you have a forensic situation to deal with. Now there did need to be a better solution in the init system space but systemd was possibly the worst answer that could be mustered for it. Systemd is merely what you get when Redhat owns the development community, not the best technical solution.
  - sliken 6y ago
    Heh, it's not that Redhat owned the devel community, it's that several redhat engineers joined the debian technical board and used their bylaws to force a quick vote.
    - deleted 6y ago
      [deleted]
    - the_why_of_y 6y ago
      You are entitled to your own opinions, but not to your own facts.
      - turminal 6y ago
        Can you provide some links about that? Or an explanation? I am genuinely interested.
        the_why_of_y 6y ago
        This was the 2014 vote of the Debian Technical Committee: https://lwn.net/Articles/585504/ https://lwn.net/Articles/585504/ Of the 8 voting members, at the time Steve Langasek and Colin Watson were currently employed and Ian Jackson had been previously employed by Canonical. None of the 8 voting members were employed by Red Hat at the time. Here's a comment with more research into affiliations at the time: https://lwn.net/Articles/585026/ https://lwn.net/Articles/585026/
- revanx_ 6y ago
  What do you mean it talks to the network? Can you give some reference?
  - dijit 6y ago
    Socket activation (by its very nature) is systemd listening to the network on your programs behalf. If nothing else.
    - revanx_ 6y ago
      I see, I've heard about it but I couldn't find any reference that systemd starts listening on sockets before the firewall service is started. Even if it did, with systemd you can setup your firewall service to start before the eth link goes up.
      - corty 6y ago
        You can't typically start the firewall before the eth link goes up, since rules that contain network interfaces might not work before those are created (e.g. in case of bridge or bonding interfaces). Systemd's "start everything at once, let the dependencies sort out automatically" is a major regression for server systems. With sysv-init you could just pick the right ordering and be done, everything was stable for every boot after that.
        genghizkhan 6y ago
        You can, using the directives "Wants=network-pre.target" & "Before=network-pre.target". This will make sure the service is up before any network interface is configured. Source: https://www.freedesktop.org/wiki/Software/systemd/NetworkTarget/ https://www.freedesktop.org/wiki/Software/systemd/NetworkTar...
        corty 6y ago
        Not quite. First, this doesn't apply to any interfaces that are created by system services like VPN tunnels. Second, you would usually want and need network-online.target, because firewall config often is applied after network-pre only. Third, dynamic stuff like VLAN interfaces also only appear after network-pre and often only after network-online. So no cookies for you. This kind of non-attention to details is actually what makes systemd bad: Everything looks like the authors laptop, if it doesn't, tough luck.
- AsyncAwait 6y ago
  > Systemd is a security nightmare I have yet to see solid evidence it is any bigger of a nightmare than a mess of bash scripts that was what came before, but ok. > taking over various network services ... poorly. The networking features of systemd are entirely optional. If you don't know how to disable them if you don't want them, the right course of action is not to blame systemd. People who grew up on SysV init like to shit on systemd as it erases their existing knowledge, but to pretend that SysV init wasn't a total, inconsistent mess or that anyone was maintaining consolekit before logind came around is distorting the truth, to put in mildly.
  - chris_wot 6y ago
    Indeed, I read the following: “systemd contains a lot of unnecessary attack surface; it attempts to do far more things than necessary and goes beyond what an init system should do.” I’d want the author to explain this further. Perhaps they could tell the admin of the system how to reduce the attack surface, detail what services it should not be providing (and why), what services it provides that are worse than the alternative, and how to turn them off or harden them. “An init system should not need many lines of code to function properly.” That’s a ridiculous statement. Lines of code is an absurd measurement to determine the security of anything.
    - corty 6y ago
      Systemd provides a lot of network functionality in systemd-networkd, journald, timesyncd, etc. that is remote attack surface. All the systemd "cloud of daemons" is tightly coupled by dbus interfaces that enable an attacker to move from one exploited system service to the next. Even if the attacker doesn't manage to find an exploit in another system service, DoS is easily possible because the DBUS interfaces are quite fragile. Even as a benevolent admin it is easily possible to get the system into a state where e.g. clean shutdown is no longer possible because systemctl doesn't want to talk to systemd any longer and you cannot fix that. systemd-udevd also has raceconditions galore, so sending any message to it in the wrong order relative to another one will kill the system, maybe even open exploit vectors. At the very least I would, for hardening, recommend not using any network-facing systemd functionality. And lines of code are not ridiculous, they are the best first-order estimate available. Of course an actual inspection of the code is better for a comparison, but that is a huge task. sloccount is quick and easy.
- tifadg1 6y ago
  why stop there - also use a system that doesn't have IME/PSP, supports coreboot.
- kd913 6y ago
  When I run systemd-analyze security systemd-networkd it seems to have set quite a lot of capabilities/restrictions. It seems there was quite a lot of restrictions in place to specifically minimize the attack service of that service. That is unlike a significant number of other services running on my system.
- amelius 6y ago
  The problem is that a modern Linux system has a microservices architecture. Systemd tries to address it as such, but it's not enough.
- easterncalculus 6y ago
  Don't forget that if you run the wrong command, you can brick your entire computer: https://github.com/systemd/systemd/issues/2402 https://github.com/systemd/systemd/issues/2402
  - Gracana 6y ago
    That really isn't systemd's fault. Software needs to manage the efi variables, so systemd mounts efivarfs writable.
    - easterncalculus 6y ago
      What software actually needs to repeatedly write to these variables? Systemd itself does, but there was absolutely a world before having this option on by default. Grub and such can just unmount after they are done.
  - sliken 6y ago
    The CVE trend for systemd is worrisome as well: https://www.cvedetails.com/product/38088/Freedesktop-Systemd.html?vendor_id=7971 https://www.cvedetails.com/product/38088/Freedesktop-Systemd... Disappointing that an init system is on the network at all.
xondono 6y ago
You mean to say me that there’s no such thing as “superior programming practices”./s I’d take a heavily used and tested system over one programmed “with superior practices”, like obsoleting rarely used code, any day of the week. Yes, heartbleed was bad, but those type of bugs are rare, and once made public patches come fast. You don’t make your system more secure by exchanging the rare occasional general bug with obscure and unknown bugs (with unknown reach). A lot of people thinking in security tend to fall for the availability bias, they want to protect themselves from the bugs that make news, while ignoring the ones that are removed day by day in a changelog of some minor utility they are using.
- MaxBarraclough 6y ago
  I'd say it depends. > heartbleed was bad, but those type of bugs are rare Not really. There's a constant stream of security vulnerabilities arising from buffer-overflows and memory-management bugs, even in the most high-profile C/C++ codebases like the Linux kernel and Chromium. C and C++ are minefields for undefined behaviour, and many security vulnerabilities can be tracked back to instances of undefined behaviour. Rewriting in a safe language, like SPARK or the safe subset of Rust, would close the door on these vulnerabilities. That's not to say I'd uncritically jump aboard a safe-Rust replacement for OpenSSL. As you say, there's much value in mature and battle-tested code, and Rust's safety guarantees wouldn't guarantee you a bug-free SSL library, they only guarantee the absence of certain kinds of errors. Even a fully formally verified implementation in SPARK could still have side-channel vulnerabilities (e.g. timing issues).
  - xondono 6y ago
    Bugs are frequent, but most of them have limited scope, bugs that break everything from computers to smart toasters are rare. As a C programmer myself I’m well aware of how big the mine field is, and I’m a big proponent for validation in the Rust style, but that was not the point. This guide advocates for replacements for programs and libraries written in C++, with most of those replacements being written also in C++, but with “superior programming practices”, even when those replacements are very rarely used in most environments.
Mikhail_K 6y ago
It's controversial only to incompetent admins, who should not be managing secure systems anyway.
Iolaum 6y ago
I stopped reading after that. I understand the author has good reasons from his perspective. I m also realizng the need for opinionated tech solutions in order to create a cohesive system. However the authors opinion is not moving towards a direction I want to follow.
- zests 6y ago
  Luckily (or perhaps unluckily for you because you stopped reading) there are plenty of systemd hardening tips in the article. Its quite strange to stop reading after an init system opinion but these init system religions are nothing if not strange.
  - Iolaum 6y ago
    It's not a religion, from my POV at least. One of the things I try to do with my tech choices is watch my delta from mainstream options, where I expect most development and bug fixes happen. Given that systemd has been adopted by the bigger linux distributions I see more value in using it and have the big vendors fix any problems than trying to use niche solutions. I m surprised that the author did have systemd hardening suggestions, didn't expect that. I 'm tempted to go back and check them.
turminal 6y ago
This guide is indeed opinionated and subjective and in many ways misses the point but the "don't use systemd" advice is among the on point ones. Still this is a minor issue for majority of users. Like most of this guide.
m463 6y ago
Yet if you had to put a server on an unsecured network, his advice would be sound. You would spend less time responding to CVEs and more time home playing with your kids (or trying to make some)
- kbknapp 6y ago
  The lack of a CVE does not imply the lack of a security vulnerability.
stjohnswarts 6y ago
When I see stuff like that I usually just stop reading and move on knowning it will eventually get deleted as I delete history over 6 months old in my browser
LargoLasskhyfv 6y ago
..."this is the truth, just how it is" It is. Anything else is brainwashing/newspeak/doublethink. Deal with it...

sliken 6y ago

Systemd is a security nightmare, a huge amount of code, taking over various network services ... poorly. Doesn't seem controversial at all to me. Gives me the heebie jeebies to think of systemd talking to the network before I even have the client firewall up. Generally if security is your top priority I'd disable as much of systemd as possible. Things like find a good local resolver (like unbound) and disable systemd's implementation, etc.

tinco 6y ago
I'd like to read a guide on hardening systemd. Systemd is really convenient and I hadn't realized it poses a large attack surface. A good list with possible attack vectors and how to mitigate them would be epic. Is it really an established idea in the security community that systemd is a security nightmare?
- tarruda 6y ago
  > Is it really an established idea in the security community that systemd is a security nightmare? Here's a list of systemd-specific CVEs over the years: https://www.cvedetails.com/product/38088/Freedesktop-Systemd.html?vendor_id=7971 https://www.cvedetails.com/product/38088/Freedesktop-Systemd... Note that these apply to all programs in systemd distribution (not sure how many of these are specific to systemd init program). It seems that a lot of criticism is due systemd doing more than a classic init process does, but some of it seem unjustified since you it is not an "all or nothing" package. For example, this specific CVE affected systemd-resolved (systemd's DNS daemon), but IIRC Debian was not affected since it did not use systemd-resolved by default: https://www.cvedetails.com/cve/CVE-2017-15908/ https://www.cvedetails.com/cve/CVE-2017-15908/ So it is perfectly fine for a distribution use systemd init system but use other network daemons.
  - Karunamon 6y ago
    >>It seems that a lot of criticism is due systemd doing more than a classic init process does, but some of it seem unjustified since you it is not an "all or nothing" package. I hate this argument because, in practice, it is an "all-or-nothing" package from a user standpoint. Packages have a terrible habit of setting dependencies on one or two of the "modules," which wind up bringing the whole thing along with them. Sure, you can "disable" it after the fact, but then you're left with a system that will break in fun and exciting ways when something a package you requested wants isn't available. If you don't want systemd, your only option at this point is also-ran distros.
    - Spivak 6y ago
      systemd is extremely modular if you’re the one compiling it (i.e. you’re a distro-builder) but not as an end-user since it’s used as the plumbing for your distro. And since distros aren’t usually in the business of telling users not to use features they ship everything because someone might want it.
  - zorked 6y ago
    The fact that systemd bundles a lot of functionality (which is different from being a monolith) means it has a disadvantage in the terrible metric of "CVE counts". Now if only the systemd-hating crowd would take a look at how many CVEs affected their DHCP client, nscd, nss and other resolvers, various PAM modules, syslog/klogd, ad-hoc init scripts writing insecurely to /tmp, ntpd, etc.
- Foxboron 6y ago
  >Is it really an established idea in the security community that systemd is a security nightmare? It's not. The presence of CVEs in software is a sign of maturity, not insecurity. It's frustrating to see people use CVE numbers to point at some larger problem. The key element is to realize that security issues are just bugs, especially in the context of C software. What you should be cautious about is upstreams that doesn't handle security issues well. Systemd is not one of these upstreams.
  - bee_rider 6y ago
    No way man, I'd much rather use this other tossed together init system that sombody started as a pet project. No CVEs!
  - qwantim1 6y ago
    By that reasoning, Flash would be safe enough to stay around, seeing how many CVEs it had (1078 since the first CVE for it was published Dec 31, 2005). It’ll be gone tomorrow though, or January 12, or later in 2021.
    - Foxboron 6y ago
      I don't think flash proves anything. It's an extreme example after all.
      - qwantim1 6y ago
        How would you modify your argument rather than dismiss the evidence against it? For example, could you propose an equation using the number of CVEs and their severity along with the the rough number of known users, showing that some curve or values would indicate maturity rather than risk? Some data for Flash[1] CVEs are available at CVE Details. Possibly you could find other products you consider safe and see how they compare. I’d be curious if an analysis would show correlation of what you’d consider greater risk with a year that Adobe started outsourcing to a particular company or decided to EOL it; I’m not proposing that quality went down due to one of those things or that they outsourced, but analyzing the data could be useful. [1]- https://www.cvedetails.com/vulnerability-list/vendor_id-53/product_id-6761/Adobe-Flash-Player.html https://www.cvedetails.com/vulnerability-list/vendor_id-53/p...
- aorth 6y ago
  > I'd like to read a guide on hardening systemd. Here is a great guide detailing some of the security features available to systemd units from earlier this year (2020): https://www.ctrl.blog/entry/systemd-service-hardening.html https://www.ctrl.blog/entry/systemd-service-hardening.html
- kd913 6y ago
  Systemd by itself comes with this wonderful analysis tool. Systemd-analyze security Systemd-analzye security <service> There it details what capabilities, and restrictions are in place for a given systemd service. From there you can edit the service to restrict even further as required if you want.
uncledave 6y ago
Completely agree with this. One of the biggest risks is using journald if you ask me. It makes logs fairly impenetrable if you have a forensic situation to deal with. Now there did need to be a better solution in the init system space but systemd was possibly the worst answer that could be mustered for it. Systemd is merely what you get when Redhat owns the development community, not the best technical solution.
- sliken 6y ago
  Heh, it's not that Redhat owned the devel community, it's that several redhat engineers joined the debian technical board and used their bylaws to force a quick vote.
  - deleted 6y ago
    [deleted]
  - the_why_of_y 6y ago
    You are entitled to your own opinions, but not to your own facts.
    - turminal 6y ago
      Can you provide some links about that? Or an explanation? I am genuinely interested.
      - the_why_of_y 6y ago
        This was the 2014 vote of the Debian Technical Committee: https://lwn.net/Articles/585504/ https://lwn.net/Articles/585504/ Of the 8 voting members, at the time Steve Langasek and Colin Watson were currently employed and Ian Jackson had been previously employed by Canonical. None of the 8 voting members were employed by Red Hat at the time. Here's a comment with more research into affiliations at the time: https://lwn.net/Articles/585026/ https://lwn.net/Articles/585026/
revanx_ 6y ago
What do you mean it talks to the network? Can you give some reference?
- dijit 6y ago
  Socket activation (by its very nature) is systemd listening to the network on your programs behalf. If nothing else.
  - revanx_ 6y ago
    I see, I've heard about it but I couldn't find any reference that systemd starts listening on sockets before the firewall service is started. Even if it did, with systemd you can setup your firewall service to start before the eth link goes up.
    - corty 6y ago
      You can't typically start the firewall before the eth link goes up, since rules that contain network interfaces might not work before those are created (e.g. in case of bridge or bonding interfaces). Systemd's "start everything at once, let the dependencies sort out automatically" is a major regression for server systems. With sysv-init you could just pick the right ordering and be done, everything was stable for every boot after that.
      - genghizkhan 6y ago
        You can, using the directives "Wants=network-pre.target" & "Before=network-pre.target". This will make sure the service is up before any network interface is configured. Source: https://www.freedesktop.org/wiki/Software/systemd/NetworkTarget/ https://www.freedesktop.org/wiki/Software/systemd/NetworkTar...
        corty 6y ago
        Not quite. First, this doesn't apply to any interfaces that are created by system services like VPN tunnels. Second, you would usually want and need network-online.target, because firewall config often is applied after network-pre only. Third, dynamic stuff like VLAN interfaces also only appear after network-pre and often only after network-online. So no cookies for you. This kind of non-attention to details is actually what makes systemd bad: Everything looks like the authors laptop, if it doesn't, tough luck.
AsyncAwait 6y ago
> Systemd is a security nightmare I have yet to see solid evidence it is any bigger of a nightmare than a mess of bash scripts that was what came before, but ok. > taking over various network services ... poorly. The networking features of systemd are entirely optional. If you don't know how to disable them if you don't want them, the right course of action is not to blame systemd. People who grew up on SysV init like to shit on systemd as it erases their existing knowledge, but to pretend that SysV init wasn't a total, inconsistent mess or that anyone was maintaining consolekit before logind came around is distorting the truth, to put in mildly.
- chris_wot 6y ago
  Indeed, I read the following: “systemd contains a lot of unnecessary attack surface; it attempts to do far more things than necessary and goes beyond what an init system should do.” I’d want the author to explain this further. Perhaps they could tell the admin of the system how to reduce the attack surface, detail what services it should not be providing (and why), what services it provides that are worse than the alternative, and how to turn them off or harden them. “An init system should not need many lines of code to function properly.” That’s a ridiculous statement. Lines of code is an absurd measurement to determine the security of anything.
  - corty 6y ago
    Systemd provides a lot of network functionality in systemd-networkd, journald, timesyncd, etc. that is remote attack surface. All the systemd "cloud of daemons" is tightly coupled by dbus interfaces that enable an attacker to move from one exploited system service to the next. Even if the attacker doesn't manage to find an exploit in another system service, DoS is easily possible because the DBUS interfaces are quite fragile. Even as a benevolent admin it is easily possible to get the system into a state where e.g. clean shutdown is no longer possible because systemctl doesn't want to talk to systemd any longer and you cannot fix that. systemd-udevd also has raceconditions galore, so sending any message to it in the wrong order relative to another one will kill the system, maybe even open exploit vectors. At the very least I would, for hardening, recommend not using any network-facing systemd functionality. And lines of code are not ridiculous, they are the best first-order estimate available. Of course an actual inspection of the code is better for a comparison, but that is a huge task. sloccount is quick and easy.
tifadg1 6y ago
why stop there - also use a system that doesn't have IME/PSP, supports coreboot.
kd913 6y ago
When I run systemd-analyze security systemd-networkd it seems to have set quite a lot of capabilities/restrictions. It seems there was quite a lot of restrictions in place to specifically minimize the attack service of that service. That is unlike a significant number of other services running on my system.
amelius 6y ago
The problem is that a modern Linux system has a microservices architecture. Systemd tries to address it as such, but it's not enough.
easterncalculus 6y ago
Don't forget that if you run the wrong command, you can brick your entire computer: https://github.com/systemd/systemd/issues/2402 https://github.com/systemd/systemd/issues/2402
- Gracana 6y ago
  That really isn't systemd's fault. Software needs to manage the efi variables, so systemd mounts efivarfs writable.
  - easterncalculus 6y ago
    What software actually needs to repeatedly write to these variables? Systemd itself does, but there was absolutely a world before having this option on by default. Grub and such can just unmount after they are done.
- sliken 6y ago
  The CVE trend for systemd is worrisome as well: https://www.cvedetails.com/product/38088/Freedesktop-Systemd.html?vendor_id=7971 https://www.cvedetails.com/product/38088/Freedesktop-Systemd... Disappointing that an init system is on the network at all.

xondono 6y ago

You mean to say me that there’s no such thing as “superior programming practices”./s I’d take a heavily used and tested system over one programmed “with superior practices”, like obsoleting rarely used code, any day of the week. Yes, heartbleed was bad, but those type of bugs are rare, and once made public patches come fast. You don’t make your system more secure by exchanging the rare occasional general bug with obscure and unknown bugs (with unknown reach). A lot of people thinking in security tend to fall for the availability bias, they want to protect themselves from the bugs that make news, while ignoring the ones that are removed day by day in a changelog of some minor utility they are using.

MaxBarraclough 6y ago
I'd say it depends. > heartbleed was bad, but those type of bugs are rare Not really. There's a constant stream of security vulnerabilities arising from buffer-overflows and memory-management bugs, even in the most high-profile C/C++ codebases like the Linux kernel and Chromium. C and C++ are minefields for undefined behaviour, and many security vulnerabilities can be tracked back to instances of undefined behaviour. Rewriting in a safe language, like SPARK or the safe subset of Rust, would close the door on these vulnerabilities. That's not to say I'd uncritically jump aboard a safe-Rust replacement for OpenSSL. As you say, there's much value in mature and battle-tested code, and Rust's safety guarantees wouldn't guarantee you a bug-free SSL library, they only guarantee the absence of certain kinds of errors. Even a fully formally verified implementation in SPARK could still have side-channel vulnerabilities (e.g. timing issues).
- xondono 6y ago
  Bugs are frequent, but most of them have limited scope, bugs that break everything from computers to smart toasters are rare. As a C programmer myself I’m well aware of how big the mine field is, and I’m a big proponent for validation in the Rust style, but that was not the point. This guide advocates for replacements for programs and libraries written in C++, with most of those replacements being written also in C++, but with “superior programming practices”, even when those replacements are very rarely used in most environments.

Mikhail_K 6y ago

It's controversial only to incompetent admins, who should not be managing secure systems anyway.

Iolaum 6y ago

I stopped reading after that. I understand the author has good reasons from his perspective. I m also realizng the need for opinionated tech solutions in order to create a cohesive system. However the authors opinion is not moving towards a direction I want to follow.

zests 6y ago
Luckily (or perhaps unluckily for you because you stopped reading) there are plenty of systemd hardening tips in the article. Its quite strange to stop reading after an init system opinion but these init system religions are nothing if not strange.
- Iolaum 6y ago
  It's not a religion, from my POV at least. One of the things I try to do with my tech choices is watch my delta from mainstream options, where I expect most development and bug fixes happen. Given that systemd has been adopted by the bigger linux distributions I see more value in using it and have the big vendors fix any problems than trying to use niche solutions. I m surprised that the author did have systemd hardening suggestions, didn't expect that. I 'm tempted to go back and check them.

turminal 6y ago

This guide is indeed opinionated and subjective and in many ways misses the point but the "don't use systemd" advice is among the on point ones. Still this is a minor issue for majority of users. Like most of this guide.

m463 6y ago

Yet if you had to put a server on an unsecured network, his advice would be sound. You would spend less time responding to CVEs and more time home playing with your kids (or trying to make some)

kbknapp 6y ago
The lack of a CVE does not imply the lack of a security vulnerability.

stjohnswarts 6y ago

When I see stuff like that I usually just stop reading and move on knowning it will eventually get deleted as I delete history over 6 months old in my browser

LargoLasskhyfv 6y ago

..."this is the truth, just how it is" It is. Anything else is brainwashing/newspeak/doublethink. Deal with it...