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!
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.
> this will not take off I'm afraid, because locking these unitfiles down is offloaded to the end-user
Maybe your point is that this isn't done by the vendor in practice. And I'm sure there's room for lots of improvement. However, one of the great things about how systemd units can be provided by the vendor and seamlessly tweaked by the administrator is that the vendor (i.e. packager and/or distro) can set these up easily.
There definitely are packages that ship with locked-down files. Tor and powerdns (pdns) are two off the top of my head.
→ Overall exposure level for pdns.service: 1.9 OK
→ Overall exposure level for tor.service: 7.1 MEDIUM
I vaguely recall looking at the slides from a talk on OpenBSD's approach to this topic, which came down to (paraphrasing from hazy memory) "if it can be disabled, people will disable it; if it needs to be configured, people won't configure it".
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.
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.
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).
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.
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.
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.
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.
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.
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!
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.
30 comments
[ 2.8 ms ] story [ 46.7 ms ] thread"Yes, it is written systemd, not system D or System D, or even SystemD. And it isn't system d either. [...]"
Yesterday's, just in case: https://us.jlcarveth.dev/post/hardening-systemd.md https://news.ycombinator.com/item?id=44928504
https://github.com/desbma/shh
EDIT: More info here: https://github.com/systemd/systemd/issues/33688
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
[2] https://github.com/netblue30/firejail/issues/3046
Maybe your point is that this isn't done by the vendor in practice. And I'm sure there's room for lots of improvement. However, one of the great things about how systemd units can be provided by the vendor and seamlessly tweaked by the administrator is that the vendor (i.e. packager and/or distro) can set these up easily.
There definitely are packages that ship with locked-down files. Tor and powerdns (pdns) are two off the top of my head.
Normally the rule is that people mis-capitalizing the name are usually critical of the project.
It's systemd, not SystemD
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/
[2]: https://sr.ht/~jamesponddotco/credential-go/
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.
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.