Hardening Systemd Services

Summary

My love for systemd is no secret, I've blogged about it more than once. I especially love systemd's ability to harden services. What does this mean exactly? Systemd offers a wealth of directives that can restrict a service's access to files, syscalls, or even the network. This gives me peace of mind, knowing that even if the software running in the service has a vulnerability, the rest of the system stays protected. The Hardening Loop Hardening a systemd service isn't a one-shot task. It's an iterative process: Add one (or a few) directives to your .service file. Reload the systemd daemon and restart your service sudo systemctl daemon-reload sudo systemctl restart example.service Verify the service still works. Repeat until the service is satisfactorily locked down. The Security Score There is an optional step between 3) and 4): using systemd-analyze security <service-name>. This command displays a table showing various directives, whether they've been applied to your service, and the potential security score improvement if a directive has yet to be applied. At the bottom of this output, you will see the total score for your service. Lower is better. Why Bother? Without hardening our services, a compromised service can become a gateway for attackers. Imagine a web server with a remote code execution flaw: if the service runs with full privilleges, an attacker could read sensitive files, modify system configurations, or even spread to other machines on the network. But with proper hardening we gain: Filesystem isolation Network isolation System call filtering With hardened systemd services, we can more effectively contain potential breaches.