When STIG Guidance Breaks Linux

Security hardening guides are meant to reduce risk, not accidentally take systems down. Unfortunately, that’s exactly what can happen if you blindly follow the remediation snippets found in the DISA STIG audit content for Ubuntu 22.04 LTS (and 24.04 LTS as well).

The rule in question is Ubuntu 22.04 LTS must configure the directories used by the system journal to be group-owned by “systemd-journal.” The questionable part is the suggested fix:

Configure Ubuntu 22.04 LTS to set the appropriate group-ownership to the directories used by the systemd journal:

Add or modify the following lines in the “/usr/lib/tmpfiles.d/systemd.conf” file:

z /run/log/journal 2640 root systemd-journal - -
z /var/log/journal 2640 root systemd-journal - -

Restart the system for the changes to take effect.

At first glance, this looks like a standard hardening rule: tighten permissions, enforce ownership, move on. However, there’s a serious problem here that will break the system.

The culprit is the 2640 permission: it allows the owner (root) to read and write, the group (systemf-journal) to read, disallows everything to others, and sets the setgid bit. The fatal issue is the lack of the execute bit. Without it, processes cannot access files inside, even if file permissions are correct.

So, if we are reckless enough to set the 2640 permissions on /run/log/journal and /var/log/journal:

• systemd-journald will be unable to write logs.
• journalctl will likely stop working.
• Services relying on logging may fail in confusing ways.
• We risk silent logging outages.

The same STIG elsewhere mentions the correct, 2750, permissions for these directories.

But why did 2640 end up there? The most likely causes are a copy-paste error from a file permission rule (0640 => 2640) and lack of proper QA. What’s important: this is not a Linux-valid directory mode for active system paths.

Another issue is that the fix requires editing the vendor-provided file, /usr/lib/tmpfiles.d/systemd.conf. Per the tmpfiles.d(5) manual,

Files in /etc/tmpfiles.d override files with the same name in /usr/lib/tmpfiles.d and /run/tmpfiles.d. Packages should install their configuration files in /usr/lib/tmpfiles.d. Files in /etc/tmpfiles.d are reserved for the local administrator, who may use this logic to override the configuration files installed by vendor packages

Therefore, it makes more sense to create an override in /etc/tmpfiles.d.

I would create /etc/tmpfiles.d/zz-journald.conf:

z /run/log/journal 2750 root systemd-journal - -
z /var/log/journal 2750 root systemd-journal - -

and then run systemd-tmpfiles --create.

Why this matters:

• /usr/lib/tmpfiles.d/ is owned by packages.
• Updates may overwrite the changes.
• /etc/tmpfiles.d/ is the documented override mechanism.

Security compliance should harden, not sabotage. When guidance contradicts fundamental filesystem rules, it’s okay — and necessary — to deviate in the name of system stability and correctness.