systemd Sandboxing, Measured Against The Job It Must Not Break

unit-hardening

The scheduler on a stock EL host runs as root with every capability the kernel has. systemd-analyze security crond.service says 9.6 UNSAFE: ProtectSystem=no, PrivateTmp=no, NoNewPrivileges=no, and a CapabilityBoundingSet holding cap_sys_admin, cap_sys_module and cap_sys_boot among the rest. This role writes a sandboxing drop-in and proves two things that are usually only asserted: systemd's own exposure number came down, and the service still does its job.

No download, and no version to pin. systemd is the distribution. What the role owns is one drop-in under /etc/systemd/system/<unit>.d/ - never the packaged unit, which the next update replaces - and the proof that what it describes is what systemd is applying.

A unit's sandbox is inherited by everything it spawns. That is the whole reason this role is worth reading before running: hardening the scheduler hardens every job on the host. Measured with a user's crontab writing to two places, a job writing into /etc stopped working at the first step of the ladder below, and nothing announced it.

The ladder, measured one step at a time on this role's own lane. Each row adds to the row above it, against crond with a user's crontab writing both to a permitted path and into /etc:

drop-in	exposure	the permitted job	the job writing into /etc
stock, no drop-in	9.6 UNSAFE	ran	ran
namespace protections, ProtectSystem=full	6.4 MEDIUM	ran	stopped
CapabilityBoundingSet trimmed to six (shipped)	5.0 MEDIUM	ran	stopped
CapabilityBoundingSet=CAP_SETUID CAP_SETGID	4.6 OK	stopped	stopped

The best score in that table is the broken one. 4.6 is the only rating systemd calls OK, and at that setting cron stopped running jobs at all - the daemon stays active and reports nothing. A role that optimised the number rather than the outcome would ship a host whose scheduler silently does nothing, which is why the shipped CapabilityBoundingSet is the six-capability set at 5.0 and why the live test asserts a job still runs before it asserts anything about the number.

PrivateTmp=yes gives the unit its own /tmp AND /var/tmp, and so does every job it starts. Anything a cron job writes there is invisible from outside the service and gone when the service restarts. This role's own test found it the hard way: a fixture writing into /var/tmp looked like a job that had stopped running, because the file outside never grew. If jobs on your host use /tmp to hand data to anything else, that is the directive to reconsider.

ProtectSystem=full, not strict. full makes /usr, /boot and /etc read-only, which is what stopped the /etc job above. strict makes the whole hierarchy read-only and is a much larger promise to make on behalf of jobs somebody else wrote. Use unit_hardening_directives to go further when you know what the unit's children do.

systemd-analyze security on a unit that does not exist exits 0. It prints "Unit nosuch.service not found, cannot analyze" and returns success, so a typo in a unit name yields a successful command and no number at all. The live test parses the number out and asserts it is there before comparing it, because an empty reading compared against anything is not a comparison.

Nothing validates a drop-in. systemd logs an unknown directive and carries on, so the test reads the values back from systemctl show - systemd's own view of what it is applying - rather than from the file the role just wrote.

License

Commercial - IaC Bazaar EULA. (c) IaC Bazaar.