← All rules
SOCLE-CLD-FSP-155// File permissionsmediumpersistent config

Verify Permissions on the journal command

Ensures the /usr/bin/journalctl binary has no group/other write or execute, no read for other, and no setuid/setgid bits, so journal access stays controlled.

Checked against the content of a persistent configuration file, the source of truth that survives reboots.

A pass proves? running now✓ on disk✓ survives rebootthe qualified verdict →
Ubuntu 22.04CIS 3.0.0Ubuntu 24.04CIS 1.0.0Ubuntu 26.04
One check, maps to 1 standard

A mapping is a cross-reference to where each standard places this requirement, anchored and cross-validated, not a claim of equivalence. A passing check is evidence toward these references, how to read it.

Why this rule matters

The journalctl binary reads the systemd journal, which can contain sensitive operational and security data. The STIG requires the command's permissions to be tightly controlled so that unprivileged users cannot tamper with the binary or use it to read more than they should. If /usr/bin/journalctl were writable by group/other it could be replaced or modified; an unexpected setuid/setgid bit would grant elevated access to the journal. The binary must have no write/execute for group or other, no read for other, and no special bits, so only authorised, privileged use of the journal command is possible.

What Pavois checks

Pavois reads the effective inode mode of /usr/bin/journalctl and asserts no setuid/setgid/sticky bits, no write/execute for group, and no write/execute/read for other. Guarded by only_if { file('/usr/bin/journalctl').exist? }. Reading the live binary's mode catches a binary that was replaced or had its bits changed after installation, exactly the tampering this STIG control guards against.

only_if { file('/usr/bin/journalctl').exist? }
describe file('/usr/bin/journalctl') do
  it { should_not be_setuid }
  it { should_not be_executable.by('group') }
  it { should_not be_writable.by('group') }
  it { should_not be_setgid }
  it { should_not be_executable.by('other') }
  it { should_not be_writable.by('other') }
  it { should_not be_readable.by('other') }
  it { should_not be_sticky }
end

How to verify it is applied

Run stat -c '%a %U %G' /usr/bin/journalctl. The expected output is 740 root root per the STIG (no write/execute for group, no access for other, no setuid/setgid). Some distributions ship 750; in all cases there must be no write for group/other and no setuid/setgid bit.

Inspect & investigate

stat /usr/bin/journalctl shows the current mode. The journal it reads is itself queried with journalctl; package integrity can be checked with dpkg --verify systemd (flags mode/owner changes against the package database). File modifications appear in /var/log/audit/audit.log if watched.

Remediation

No automated harden plan is defined for this rule yet, so apply it manually: chown root:root /usr/bin/journalctl then chmod 0740 /usr/bin/journalctl (per the Ubuntu STIG).

Pavois applies this with its own harden engine, the plan below, not a shell script:

mode0740
path/usr/bin/journalctl
resourcefile
pavois harden plan local

where the target is local, a user@host SSH alias, or a container , Docs

Impact & precautions

If the binary is writable by non-root, it can be trojaned to capture or hide log data; an unexpected setuid bit would let any user read the full journal. Precautions: setting 0740 removes execute for other, which means non-root users can no longer run journalctl at all, confirm no unprivileged operator or monitoring agent relies on it before applying, or grant journal access via membership of the systemd-journal group with an appropriate mode instead. A systemd package update may reset the binary's permissions, so re-verify after upgrades.

Standards mapping

StandardReferenceTypeVersionConfidence
DISA STIGUBTU-22-232140, UBTU-24-700030directper OS STIG releasehigh

Each reference is a cross-reference anchored in the upstream benchmark and cross-validated against the SCAP Security Guide and ansible-lockdown, not a claim of equivalence. Direct = a prescriptive, line-level requirement; supporting = an abstract control family (NIST) the check provides evidence toward. How to read a mapping.

Sources & references