7 ms·

SystemD Service Hardening

297 points by todsacerdoti 1y ago

deleted 1y ago
[deleted]
Unirely01 1y ago
[dead]
bananapub 1y ago
this is ... very low quality, and very low density. why did someone feel it was useful to post to HN?
- columb 1y ago
  Could you please expand on the "very low quality" claim? What's missing for you here? How would you raise a bar on this piece to make it more of a high quality, security focused content? Genuine question.
0xfedcafe 1y ago
Best systemd hardening is switching to OpenRC or runit
- mcpherrinm 1y ago
  Do you have any references for doing similar system hardening under either of those?
  - 0xfedcafe 1y ago
    Yeah. With OpenRC or runit, the idea is you just layer the security on yourself since the base is so minimal. Honestly, the best place to start for any system is Madaidan’s Linux Hardening Guide. It’s super thorough and works for pretty much anything. From there, you can add other tools. The Gentoo Hardened setup with SELinux is an option, but it’s a ton of work. AppArmor is way easier for just locking down specific services and apps, it’s what Alpine uses and it’s pretty effective. And for sandboxing random apps, Firejail is perfect. You can just wrap it around your browser or anything else you don’t fully trust to keep it contained. Gives you a lot of control. https://madaidans-insecurities.github.io/guides/linux-hardening.html https://madaidans-insecurities.github.io/guides/linux-harden... https://discuss.privacyguides.net/t/add-gentoo-linux-void-linux-and-alpine-linux/12221 https://discuss.privacyguides.net/t/add-gentoo-linux-void-li... https://github.com/gentoo/hardened-refpolicy https://github.com/gentoo/hardened-refpolicy https://krython.com/post/hardening-alpine-linux-system-security/ https://krython.com/post/hardening-alpine-linux-system-secur...
- fsflover 1y ago
  No, switching to Qubes OS is the real hardening.
  - 0xfedcafe 1y ago
    also true
- gf000 1y ago
  An unbootable system is indeed harder to exploit! /s
  - yjftsjthsd-h 1y ago
    Why would OpenRC or runit be any less likely to boot?
    - gf000 1y ago
      My response was a joke to a low-effort comment, but in general - systemd is complex because it solves the complex problem of booting up a system, complete with error handling, logging, etc. Many of the alternatives simply ignore part of the problem space, making the simple case simpler, but the complex case impossible.
deleted 1y ago
[deleted]
igorramazanov 1y ago
Automatic systemd service hardening guided by strace profiling https://github.com/desbma/shh https://github.com/desbma/shh
- isodude 1y ago
  A nice thing I found is that if you do (which I see they did not in the examples) # ProtectSystem= you can do TemporaryFileSystem=/:ro BindReadOnly=/usr/bin/binary /lib /lib64 /usr/lib usr/lib64 <paths you want to read> And essentially just including the binary and the path you want available. ProtectSystem= is currently not compatible with this behavior. EDIT: More info here: https://github.com/systemd/systemd/issues/33688 https://github.com/systemd/systemd/issues/33688
- aidenn0 1y ago
  Seems that might be an issue for something that wants to e.g. send an e-mail when an error occurs?
DyslexicAtheist 1y ago
these Hardening variables have been discussed some years back[1]. this will not take off I'm afraid, because locking these unitfiles down is offloaded to the end-user (I've yet to see maintainers embrace shipping locked down files). Maybe they will? But this same approach hasn't worked with apparmor so why should it work with systemd? Who will do the job? If you consider apparmor maintainers provide skeleton-templates in many cases that will make the parser stop complaining. ("look I have a profile so apparmor shuts up, but don't take too close a look OK") Then there is firejail, which some argue[2] is snake-oil considering the high level of administrative glue compared to its massive attack-surface (also it's a setuid binary). I didn't mention SElinux since I don't know a single person who had the joy (or pain depending on perspective) of working with it. But again, seems the expectation to implement security with it is shifted to the user. [1] https://news.ycombinator.com/item?id=22993304 https://news.ycombinator.com/item?id=22993304 [2] https://github.com/netblue30/firejail/issues/3046 https://github.com/netblue30/firejail/issues/3046
- ptman 1y ago
  It would be nice to be possible to do the hardening of services via allowlisting instead. E.g. AllowNothing=true and then start adding what is allowed to make the service function.
  - isodude 1y ago
    I think that pledge[0] offers that functionality [0] https://github.com/jart/pledge https://github.com/jart/pledge
- dralley 1y ago
  > this will not take off I'm afraid, because locking these unitfiles down is offloaded to the end-user (I've yet to see maintainers embrace shipping locked down files). https://fedoraproject.org/wiki/Changes/SystemdSecurityHardening https://fedoraproject.org/wiki/Changes/SystemdSecurityHarden...
  - DyslexicAtheist 1y ago
calvinmorrison 1y ago
The security issues with Linux will only be solved once lennart pulls the entire userland into the systemd repo
egberts1 1y ago
So, no more DEFAULT-DENY for SystemD?
pilif 1y ago
color me surprised to see an article mostly constructive and positive about systemd using the wrong capitalization of the project name. Normally the rule is that people mis-capitalizing the name are usually critical of the project. It's systemd, not SystemD
jamesponddotco 1y ago
Another great security feature systemd provides is credential management[1], which allows you to expose credentials to an application in a more secure way than, say, an environment variable or a file in the filesystem. When Vault is not available, if I’m working on a side project, for example, that’s what I always go for. Even wrote a small Go package[2] to get said credentials when your application is running inside a service with that feature. [1]: https://systemd.io/CREDENTIALS/ https://systemd.io/CREDENTIALS/ [2]: https://sr.ht/~jamesponddotco/credential-go/ https://sr.ht/~jamesponddotco/credential-go/
- TheDong 1y ago
  I see we've decided to take the path of nodejs and npm, where 2-liners deserve their own package. dir, err := os.Getenv("CREDENTIALS_DIRECTORY") cred, err := os.ReadFile(filepath.Join(dir, "name")) That's less complexity than left-pad. I thought the go culture was that dependencies are bad, and abstractions (i.e. any function calls) are confusing and bad, so it's better to just inline stuff like this and write it fresh each time you need it.
  - jamesponddotco 1y ago
    I was writing the same few lines for every project, so why not make it its own package? For my projects I can just include the dependency, as I wrote it and don’t mind using it. Other people can copy it instead, since the proverb goes “a little copying is better than a little dependency”.
    - skydhash 1y ago
      Editor macros/snippets?
      - jamesponddotco 1y ago
        Didn’t think of that ¯\_(ツ)_/¯
    - TheDong 1y ago
sgt 1y ago
I'd hate to restrict Docker like that - depending on what you run inside of Docker, it would be very hard to narrow it down to the right security tuning settings. In that case, it's actually safer and more predictable to run it in systemd (arguably).
- jcgl 1y ago
  What would be so hard about it? Also, this is not docker--it's podman. Which has a much simpler execution model than Docker. With it, it shouldn't be any harder to narrow down what the problem is, compared to running a non-containerized service.
smjburton 1y ago
Thanks for sharing this. It looks like you can also use "systemd-analyze" with the "--user" flag to inspect systemd user units as well ("systemd-analyze --user security"). I've started using systemd more now that I've transitioned my containers to Podman, and this will be a helpful utility to improve the security of my systemd unit/container services.
immibis 1y ago
The unreasonable effectiveness of writing a security scanner. People will do anything it takes to make the scanner give a perfect score, regardless of whether it makes sense.
delusional 1y ago
Nitpick and title correction: The proper spelling of systemd is systemd, not SystemD. According to their brand page: Yes, it is written systemd, not system D or System D, or even SystemD. And it isn't system d either. Why? Because it's a system daemon, and under Unix/Linux those are in lower case, and get suffixed with a lower case d. And since systemd manages the system, it's called systemd.
- bee_rider 1y ago
  Interesting! I’ve mostly seen it written as systemD. I wonder why that seems to be so popular…
  - roryirvine 1y ago
    Many of the more juvenile systemd haters used to deliberately spell it that way. As an insult, it was rather less successful than the "Micro$oft" / "Slowaris" / "HP-SUX" mockery from the 1990s - but it did manage to sow enough confusion that that it still pops up regularly today, even in contexts that are otherwise neutral or positive about it.
    - bee_rider 1y ago
      That’s funny, I’m not even sure what the D is supposed to expand to, in that insult. What a silly and lame thing to use as an insult. I’ve been using it because having some random letter capitalized seems to be the totally unsurprising for this sort of plumbing software. (And by plumbing, I mean: very useful and helpful boring stuff that deals with messy problems that I’m happy not to care about, just to be clear that I mean it positively, haha).
0xbadcafebee 1y ago
It would be cool to have a repo with suggested hardening for common services, since there's so many different hardening options. One of the things you might notice from lots of users using common suggestions, is that the permissions often need to be opened up more than you'd think, to support edge cases.
- c0balt 1y ago
  > It would be cool to have a repo with suggested hardening for common services From packaging stuff for nixpkgs, a distro that often is without upstream support, it is usually very useful to look at how mainstream distro package services. Those hardening steps also tend to be well tested even if sometimes a bit lax. If you want to find out how, e. G., postgresql can be hardened, consider looking at the Debian, Ubuntu and/or RHEL packages as a starting point.
  - 0xbadcafebee 1y ago
    Distros don't usually do security hardening, unless the distro is security-specific. They slap something generic on like AppArmor or SELinux and call it a day. (This article is the proof of that... all the default services are not hardened). Usually this is a good thing, as it prioritizes usability, and lets the user harden as they wish.
neuroelectron 1y ago
Great article. I really appreciate the list of properties and the "check the man pages, good luck" advice. systemd is really a great piece of software I would enjoy deploying on my hosts!
temp0826 1y ago
Why don't distros flip more of these switches? Are there cons of being more aggressive with these settings? It's really a lot for many people to tinker with.
- colinsane 1y ago
  > Are there cons of being more aggressive with these settings? well, the con is you might unknowingly break some setups. take NetworkManager: after tightening it down, did you check both IPv4 and IPv6 connectivity? did you check that both the `dns=systemd-resolved` and `dns=default` modes of operation (i.e. who manages /etc/resolv.conf) work? did you check its ModemManager integrations, that it can still manage cellular connections? did you check that the openvpn and cisco anyconnect plugins still work? what about the NetworkManager-dispatcher hooks? > Why don't distros flip more of these switches? besides the bit of "how many distro maintainers actually understand the thing they're maintaining well enough to know which switches can be flipped without breaking more than 0.01% of user setups", there's the bit of "should these flags be owned by the distro, or by the upstream package?" if the distro manages these, they'll get more regressions on the next upstream release. if the upstream sets these, they can't be as aggressive without breaking one or two of their downstreams.
- mkipper 1y ago
  This question is sorta similar to "Why don't distros enable restrictive MAC policies by default" Maintainers _could_ take the time to lock down sshd and limit the damage it can do if exploited, but there are costs associated with that: 1. Upfront development cost 2. Maintenance cost from handling bug reports (lots of edge cases for users) 3. Maintenance cost from keeping this aligned with upstream changes You could extend this argument and say that distros shouldn't bother with _any_ security features, but part of the job of a distro maintainer is to strike a balance here, and similar to SELinux / AppArmor / whatever, most mainstream desktop distro maintainers probably don't think the juice is worth the squeeze.
- wakawaka28 1y ago
  I don't know but I would imagine the settings are sometimes new. Not everyone is a systemd nerd, and even if they were you may actually break stuff for old versions of systemd if you try to turn them on. We could also ask why nobody seems to use SELinux or AppArmor, or any other random security feature. Most distros have these things available but most developers and users are not familiar, don't truly need it, etc.
ibizaman 1y ago
Nice tip on debugging syscall issues!
eliaspro 1y ago
Quoting https://brand.systemd.io/#:~:text=Yes,%20it%20is%20written%20systemd https://brand.systemd.io/#:~:text=Yes,%20it%20is%20written%2... "Yes, it is written systemd, not system D or System D, or even SystemD. And it isn't system d either. [...]"
- viraptor 1y ago
  At some point, if you have to write articles about the proper spelling of the name, maybe you should just accept the alternative names as well. Also looking at you Datadog and Cloudflare. (The employees of the second one are especially allergic to CloudFlare for some reason)
  - brongondwana 1y ago
    We tried very hard to convert FastMail to Fastmail and... it's been about 90% successful but there's definitely a bunch of things out there spelled the old way. We just joke about BIG M occasionally. [TIL - it's not even as old as me!] https://australianfoodtimeline.com.au/1978-launch-of-big-m/ https://australianfoodtimeline.com.au/1978-launch-of-big-m/
  - johnisgood 1y ago
    And I tried telling people "news-teller" (or "news teller") is a better word than "herald", and I got told off, so I dunno. By the way, I love that the OP used the Text Fragment (Scroll-to-Text Fragment) feature. I hope it is going to catch on more, quite helpful / useful.
  - ciupicri 1y ago
    I guess you could say the same about pronouns. Anyway, why would someone use the spelling with upper D beats me. It's not proper English.
    - viraptor 1y ago
      > I guess you could say the same about pronouns. Entirely different thing. Software/things are not the same as people. > why would someone use the spelling with upper D SystemV, Zyklon B, Vampire hunter D, Plan B, Model T, Type O, ... It's extremely common.
jauntywundrkind 1y ago
Much better article with very real tips about what options to try than yesterday's (weirdly flagged/dead?) post on the topic. Which while I really enjoyed lacked substance; I was in the comments trying to provide a more useful basis with some real examples, but this is an exemplary list of awesome ways systemd can easily quickly readily provide aassive boost to isolation & security. Great write up! Yesterday's, just in case: https://us.jlcarveth.dev/post/hardening-systemd.md https://us.jlcarveth.dev/post/hardening-systemd.md https://news.ycombinator.com/item?id=44928504 https://news.ycombinator.com/item?id=44928504
- keysdev 1y ago
  Maybe fix the certificate issue on the site. Some browser doesnt event let one go forward with a bad cert.
Faaak 1y ago
And that's something that's impossible to do with old init scripts, that are all unique in their way and not uniform at all.
- lillecarl 1y ago
  You can ofcourse achieve all these things in your init scripts which are unique in their way and not uniform at all, just to give credit where credit is due. But systemd makes it practical to use our beloved kernel and it's features in an uniform and standard way... :) I started my Linux journey so late I can't imagine living without systemd, the few systems I've encountered without systemd are such a major PITA to use. I recently discovered "unshare" which I could use to remount entire /nix RW for some hardlinking shenanigans without affecting other processes. systemd is so good, warty UX when interacting with it but the alternative is honestly Windows in my case.
  - FooBarWidget 1y ago
    Aside, I'm quite surprise that systemd won out, given all the hate for so many years. You got nearly every forum and HN thread that even tangently mention systemd, flooded with people proclaiming systemd to be the spawn of the devil "forced down their throat". At the same time I noticed that a lot of regular Linux users (like developers that just want to deploy stuff) seemed to like systemd unit files. I guess all those complainers, however vocal, were neither the majority, nor the people who actually maintained distributions. This feeling is particular striking for me, because I once worked on a Linux project with the aim of improving packaging and software distribution. We also got a lot of hate, mainly for not being .deb or.rpm, and it looked to me as if the hate was a large reason for the failure of the project.
    - bluGill 1y ago
      Systemd won because for all the deserved hate it solves real problems that nobody else was really trying (or their attempts were worse). There are some really good points to systemd - you just have to takes the bad with it.

297 points by todsacerdoti 1y ago

deleted 1y ago

[deleted]

Unirely01 1y ago

[dead]

bananapub 1y ago

this is ... very low quality, and very low density. why did someone feel it was useful to post to HN?

columb 1y ago
Could you please expand on the "very low quality" claim? What's missing for you here? How would you raise a bar on this piece to make it more of a high quality, security focused content? Genuine question.

0xfedcafe 1y ago

Best systemd hardening is switching to OpenRC or runit

mcpherrinm 1y ago
Do you have any references for doing similar system hardening under either of those?
- 0xfedcafe 1y ago
  Yeah. With OpenRC or runit, the idea is you just layer the security on yourself since the base is so minimal. Honestly, the best place to start for any system is Madaidan’s Linux Hardening Guide. It’s super thorough and works for pretty much anything. From there, you can add other tools. The Gentoo Hardened setup with SELinux is an option, but it’s a ton of work. AppArmor is way easier for just locking down specific services and apps, it’s what Alpine uses and it’s pretty effective. And for sandboxing random apps, Firejail is perfect. You can just wrap it around your browser or anything else you don’t fully trust to keep it contained. Gives you a lot of control. https://madaidans-insecurities.github.io/guides/linux-hardening.html https://madaidans-insecurities.github.io/guides/linux-harden... https://discuss.privacyguides.net/t/add-gentoo-linux-void-linux-and-alpine-linux/12221 https://discuss.privacyguides.net/t/add-gentoo-linux-void-li... https://github.com/gentoo/hardened-refpolicy https://github.com/gentoo/hardened-refpolicy https://krython.com/post/hardening-alpine-linux-system-security/ https://krython.com/post/hardening-alpine-linux-system-secur...
fsflover 1y ago
No, switching to Qubes OS is the real hardening.
- 0xfedcafe 1y ago
  also true
gf000 1y ago
An unbootable system is indeed harder to exploit! /s
- yjftsjthsd-h 1y ago
  Why would OpenRC or runit be any less likely to boot?
  - gf000 1y ago
    My response was a joke to a low-effort comment, but in general - systemd is complex because it solves the complex problem of booting up a system, complete with error handling, logging, etc. Many of the alternatives simply ignore part of the problem space, making the simple case simpler, but the complex case impossible.

deleted 1y ago

[deleted]

igorramazanov 1y ago

Automatic systemd service hardening guided by strace profiling https://github.com/desbma/shh https://github.com/desbma/shh

isodude 1y ago
A nice thing I found is that if you do (which I see they did not in the examples) # ProtectSystem= you can do TemporaryFileSystem=/:ro BindReadOnly=/usr/bin/binary /lib /lib64 /usr/lib usr/lib64 <paths you want to read> And essentially just including the binary and the path you want available. ProtectSystem= is currently not compatible with this behavior. EDIT: More info here: https://github.com/systemd/systemd/issues/33688 https://github.com/systemd/systemd/issues/33688
aidenn0 1y ago
Seems that might be an issue for something that wants to e.g. send an e-mail when an error occurs?

DyslexicAtheist 1y ago

these Hardening variables have been discussed some years back[1]. this will not take off I'm afraid, because locking these unitfiles down is offloaded to the end-user (I've yet to see maintainers embrace shipping locked down files). Maybe they will? But this same approach hasn't worked with apparmor so why should it work with systemd? Who will do the job? If you consider apparmor maintainers provide skeleton-templates in many cases that will make the parser stop complaining. ("look I have a profile so apparmor shuts up, but don't take too close a look OK") Then there is firejail, which some argue[2] is snake-oil considering the high level of administrative glue compared to its massive attack-surface (also it's a setuid binary). I didn't mention SElinux since I don't know a single person who had the joy (or pain depending on perspective) of working with it. But again, seems the expectation to implement security with it is shifted to the user. [1] https://news.ycombinator.com/item?id=22993304 https://news.ycombinator.com/item?id=22993304 [2] https://github.com/netblue30/firejail/issues/3046 https://github.com/netblue30/firejail/issues/3046

ptman 1y ago
It would be nice to be possible to do the hardening of services via allowlisting instead. E.g. AllowNothing=true and then start adding what is allowed to make the service function.
- isodude 1y ago
  I think that pledge[0] offers that functionality [0] https://github.com/jart/pledge https://github.com/jart/pledge
dralley 1y ago
> this will not take off I'm afraid, because locking these unitfiles down is offloaded to the end-user (I've yet to see maintainers embrace shipping locked down files). https://fedoraproject.org/wiki/Changes/SystemdSecurityHardening https://fedoraproject.org/wiki/Changes/SystemdSecurityHarden...
- DyslexicAtheist 1y ago

calvinmorrison 1y ago

The security issues with Linux will only be solved once lennart pulls the entire userland into the systemd repo

egberts1 1y ago

So, no more DEFAULT-DENY for SystemD?

pilif 1y ago

color me surprised to see an article mostly constructive and positive about systemd using the wrong capitalization of the project name. Normally the rule is that people mis-capitalizing the name are usually critical of the project. It's systemd, not SystemD

jamesponddotco 1y ago

Another great security feature systemd provides is credential management[1], which allows you to expose credentials to an application in a more secure way than, say, an environment variable or a file in the filesystem. When Vault is not available, if I’m working on a side project, for example, that’s what I always go for. Even wrote a small Go package[2] to get said credentials when your application is running inside a service with that feature. [1]: https://systemd.io/CREDENTIALS/ https://systemd.io/CREDENTIALS/ [2]: https://sr.ht/~jamesponddotco/credential-go/ https://sr.ht/~jamesponddotco/credential-go/

TheDong 1y ago
I see we've decided to take the path of nodejs and npm, where 2-liners deserve their own package. dir, err := os.Getenv("CREDENTIALS_DIRECTORY") cred, err := os.ReadFile(filepath.Join(dir, "name")) That's less complexity than left-pad. I thought the go culture was that dependencies are bad, and abstractions (i.e. any function calls) are confusing and bad, so it's better to just inline stuff like this and write it fresh each time you need it.
- jamesponddotco 1y ago
  I was writing the same few lines for every project, so why not make it its own package? For my projects I can just include the dependency, as I wrote it and don’t mind using it. Other people can copy it instead, since the proverb goes “a little copying is better than a little dependency”.
  - skydhash 1y ago
    Editor macros/snippets?
    - jamesponddotco 1y ago
      Didn’t think of that ¯\_(ツ)_/¯
  - TheDong 1y ago

sgt 1y ago

I'd hate to restrict Docker like that - depending on what you run inside of Docker, it would be very hard to narrow it down to the right security tuning settings. In that case, it's actually safer and more predictable to run it in systemd (arguably).

jcgl 1y ago
What would be so hard about it? Also, this is not docker--it's podman. Which has a much simpler execution model than Docker. With it, it shouldn't be any harder to narrow down what the problem is, compared to running a non-containerized service.

smjburton 1y ago

Thanks for sharing this. It looks like you can also use "systemd-analyze" with the "--user" flag to inspect systemd user units as well ("systemd-analyze --user security"). I've started using systemd more now that I've transitioned my containers to Podman, and this will be a helpful utility to improve the security of my systemd unit/container services.

immibis 1y ago

The unreasonable effectiveness of writing a security scanner. People will do anything it takes to make the scanner give a perfect score, regardless of whether it makes sense.

delusional 1y ago

Nitpick and title correction: The proper spelling of systemd is systemd, not SystemD. According to their brand page: Yes, it is written systemd, not system D or System D, or even SystemD. And it isn't system d either. Why? Because it's a system daemon, and under Unix/Linux those are in lower case, and get suffixed with a lower case d. And since systemd manages the system, it's called systemd.

bee_rider 1y ago
Interesting! I’ve mostly seen it written as systemD. I wonder why that seems to be so popular…
- roryirvine 1y ago
  Many of the more juvenile systemd haters used to deliberately spell it that way. As an insult, it was rather less successful than the "Micro$oft" / "Slowaris" / "HP-SUX" mockery from the 1990s - but it did manage to sow enough confusion that that it still pops up regularly today, even in contexts that are otherwise neutral or positive about it.
  - bee_rider 1y ago
    That’s funny, I’m not even sure what the D is supposed to expand to, in that insult. What a silly and lame thing to use as an insult. I’ve been using it because having some random letter capitalized seems to be the totally unsurprising for this sort of plumbing software. (And by plumbing, I mean: very useful and helpful boring stuff that deals with messy problems that I’m happy not to care about, just to be clear that I mean it positively, haha).

0xbadcafebee 1y ago

It would be cool to have a repo with suggested hardening for common services, since there's so many different hardening options. One of the things you might notice from lots of users using common suggestions, is that the permissions often need to be opened up more than you'd think, to support edge cases.

c0balt 1y ago
> It would be cool to have a repo with suggested hardening for common services From packaging stuff for nixpkgs, a distro that often is without upstream support, it is usually very useful to look at how mainstream distro package services. Those hardening steps also tend to be well tested even if sometimes a bit lax. If you want to find out how, e. G., postgresql can be hardened, consider looking at the Debian, Ubuntu and/or RHEL packages as a starting point.
- 0xbadcafebee 1y ago
  Distros don't usually do security hardening, unless the distro is security-specific. They slap something generic on like AppArmor or SELinux and call it a day. (This article is the proof of that... all the default services are not hardened). Usually this is a good thing, as it prioritizes usability, and lets the user harden as they wish.

neuroelectron 1y ago

Great article. I really appreciate the list of properties and the "check the man pages, good luck" advice. systemd is really a great piece of software I would enjoy deploying on my hosts!

temp0826 1y ago

Why don't distros flip more of these switches? Are there cons of being more aggressive with these settings? It's really a lot for many people to tinker with.

colinsane 1y ago
> Are there cons of being more aggressive with these settings? well, the con is you might unknowingly break some setups. take NetworkManager: after tightening it down, did you check both IPv4 and IPv6 connectivity? did you check that both the `dns=systemd-resolved` and `dns=default` modes of operation (i.e. who manages /etc/resolv.conf) work? did you check its ModemManager integrations, that it can still manage cellular connections? did you check that the openvpn and cisco anyconnect plugins still work? what about the NetworkManager-dispatcher hooks? > Why don't distros flip more of these switches? besides the bit of "how many distro maintainers actually understand the thing they're maintaining well enough to know which switches can be flipped without breaking more than 0.01% of user setups", there's the bit of "should these flags be owned by the distro, or by the upstream package?" if the distro manages these, they'll get more regressions on the next upstream release. if the upstream sets these, they can't be as aggressive without breaking one or two of their downstreams.
mkipper 1y ago
This question is sorta similar to "Why don't distros enable restrictive MAC policies by default" Maintainers _could_ take the time to lock down sshd and limit the damage it can do if exploited, but there are costs associated with that: 1. Upfront development cost 2. Maintenance cost from handling bug reports (lots of edge cases for users) 3. Maintenance cost from keeping this aligned with upstream changes You could extend this argument and say that distros shouldn't bother with _any_ security features, but part of the job of a distro maintainer is to strike a balance here, and similar to SELinux / AppArmor / whatever, most mainstream desktop distro maintainers probably don't think the juice is worth the squeeze.
wakawaka28 1y ago
I don't know but I would imagine the settings are sometimes new. Not everyone is a systemd nerd, and even if they were you may actually break stuff for old versions of systemd if you try to turn them on. We could also ask why nobody seems to use SELinux or AppArmor, or any other random security feature. Most distros have these things available but most developers and users are not familiar, don't truly need it, etc.

ibizaman 1y ago

Nice tip on debugging syscall issues!

eliaspro 1y ago

Quoting https://brand.systemd.io/#:~:text=Yes,%20it%20is%20written%20systemd https://brand.systemd.io/#:~:text=Yes,%20it%20is%20written%2... "Yes, it is written systemd, not system D or System D, or even SystemD. And it isn't system d either. [...]"

viraptor 1y ago
At some point, if you have to write articles about the proper spelling of the name, maybe you should just accept the alternative names as well. Also looking at you Datadog and Cloudflare. (The employees of the second one are especially allergic to CloudFlare for some reason)
- brongondwana 1y ago
  We tried very hard to convert FastMail to Fastmail and... it's been about 90% successful but there's definitely a bunch of things out there spelled the old way. We just joke about BIG M occasionally. [TIL - it's not even as old as me!] https://australianfoodtimeline.com.au/1978-launch-of-big-m/ https://australianfoodtimeline.com.au/1978-launch-of-big-m/
- johnisgood 1y ago
  And I tried telling people "news-teller" (or "news teller") is a better word than "herald", and I got told off, so I dunno. By the way, I love that the OP used the Text Fragment (Scroll-to-Text Fragment) feature. I hope it is going to catch on more, quite helpful / useful.
- ciupicri 1y ago
  I guess you could say the same about pronouns. Anyway, why would someone use the spelling with upper D beats me. It's not proper English.
  - viraptor 1y ago
    > I guess you could say the same about pronouns. Entirely different thing. Software/things are not the same as people. > why would someone use the spelling with upper D SystemV, Zyklon B, Vampire hunter D, Plan B, Model T, Type O, ... It's extremely common.

jauntywundrkind 1y ago

Much better article with very real tips about what options to try than yesterday's (weirdly flagged/dead?) post on the topic. Which while I really enjoyed lacked substance; I was in the comments trying to provide a more useful basis with some real examples, but this is an exemplary list of awesome ways systemd can easily quickly readily provide aassive boost to isolation & security. Great write up! Yesterday's, just in case: https://us.jlcarveth.dev/post/hardening-systemd.md https://us.jlcarveth.dev/post/hardening-systemd.md https://news.ycombinator.com/item?id=44928504 https://news.ycombinator.com/item?id=44928504

keysdev 1y ago
Maybe fix the certificate issue on the site. Some browser doesnt event let one go forward with a bad cert.

Faaak 1y ago

And that's something that's impossible to do with old init scripts, that are all unique in their way and not uniform at all.

lillecarl 1y ago
You can ofcourse achieve all these things in your init scripts which are unique in their way and not uniform at all, just to give credit where credit is due. But systemd makes it practical to use our beloved kernel and it's features in an uniform and standard way... :) I started my Linux journey so late I can't imagine living without systemd, the few systems I've encountered without systemd are such a major PITA to use. I recently discovered "unshare" which I could use to remount entire /nix RW for some hardlinking shenanigans without affecting other processes. systemd is so good, warty UX when interacting with it but the alternative is honestly Windows in my case.
- FooBarWidget 1y ago
  Aside, I'm quite surprise that systemd won out, given all the hate for so many years. You got nearly every forum and HN thread that even tangently mention systemd, flooded with people proclaiming systemd to be the spawn of the devil "forced down their throat". At the same time I noticed that a lot of regular Linux users (like developers that just want to deploy stuff) seemed to like systemd unit files. I guess all those complainers, however vocal, were neither the majority, nor the people who actually maintained distributions. This feeling is particular striking for me, because I once worked on a Linux project with the aim of improving packaging and software distribution. We also got a lot of hate, mainly for not being .deb or.rpm, and it looked to me as if the hate was a large reason for the failure of the project.
  - bluGill 1y ago
    Systemd won because for all the deserved hate it solves real problems that nobody else was really trying (or their attempts were worse). There are some really good points to systemd - you just have to takes the bad with it.