5 ms·

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 att

by 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.

by tinco 6y ago

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.