SystemD Service Hardening

Summary

Controversy aside, systemd provides us a very complete, robust method of controlling services (amongst a multitude of other Linux things). For a lot of things though, this is optimized for success out of the box and not necessarily security. Such is the way of many IT endeavors. This doc though is meant to provide a snapshot of a number of hardening options that you can apply to systemd service units and podman quadlets to increase the overall security posture and reduce both the likelihood of compromise, as well as the blast radius post-exploitation.By no means is this a prescriptive guide for securing systemd services. All services will require different configurations based on their required capabilities. You will have to experiment and review logs when things inevitably break to make corrections. Securing your infrastructure is your responsibility and this is meant to be a tool in your belt, not a guaranteed solution.SystemD Security AnalysisBefore we can decide how to increase our systemd unit’s security, we have to understand where we’re starting. There’s a tool for this. You can run it to analyze the entirety of the list of deployed units, or you can analyze one specific unit and all its details. The latter is the method that we’ll mostly focus on here, but for the sake of thoroughness I will show you both. The former is a good way of getting a high-level idea of your overall system’s security posture.In a terminal, run the following…sudo systemd-analyze securityYou should see something like this…Bonus points for anyone who can tell me what distribution I’m running based solely on the above content…So, that’s a lot of red… Is Linux inherently insecure…? Well, no, but also yes. Linux has lots of issues with it, just as any behemoth of an operating system, but we have a lot going for us too, and let’s talk about that.And yes, for all the Stallman incarnates out there, I understand that Linux is a kernel and GNU corelibs and userspace all unite in some unholy ce...