https://www.linuxhosted.com/tags/linux-security/Recent content in Linux-Security on LinuxHosted.comHugo -- gohugo.ioenLinuxHosted.comTue, 20 Oct 2026 00:00:00 +0000https://www.linuxhosted.com/post/harden-systemd-service-ten-directives-protectsystem-nonewprivileges-friends/Tue, 20 Oct 2026 00:00:00 +0000https://www.linuxhosted.com/post/harden-systemd-service-ten-directives-protectsystem-nonewprivileges-friends/ <p>Run <code>systemd-analyze security</code> against two ordinary services on the same host and the scores can land almost six points apart — one near UNSAFE, the other down close to OK — without either service being broken or badly written. On a stock Ubuntu box running systemd 259, <code>cron.service</code> measures 9.6 UNSAFE while <code>chrony.service</code> measures 3.7 OK, per <a href="https://bulwark.nrl.ai/articles/systemd-service-sandboxing">Bulwark's directive-by-directive sandboxing guide</a>. The gap isn't about code quality — cron genuinely needs broad access to run arbitrary jobs as arbitrary users, while Debian and Ubuntu ship chrony's unit file with a static non-root user, <code>ProtectSystem=strict</code>, and most of its Linux capabilities already stripped. Every systemd service inherits whatever the handful of directives in its <code>[Service]</code> block grant it, and by default that's close to everything the host can do. This guide works through ten of those directives that do most of the real work, the supporting ones worth adding alongside them, and <code>systemd-analyze security</code> as the way to confirm any of it actually moved the needle.</p>