← All rules
SOCLE-CLD-FSP-103// File ownershipmediumfilesystem state

Verify User Who Owns /var/log/secure File

Ensures the authentication log /var/log/secure is owned by the syslog user.

Checked against a path’s metadata, mode, owner, group, SUID/SGID.

A pass proves✓ running now✓ on disk✓ survives rebootthe qualified verdict →
Debian 12CIS 1.1.0Debian 13CIS 1.0.0FedoraRHEL 10 / Rocky 10 / AlmaLinux 10RHEL 8 / Rocky 8 / AlmaLinux 8CIS 4.0.0RHEL 9 / Rocky 9 / AlmaLinux 9CIS 2.0.0Ubuntu 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

/var/log/secure records authentication and authorization activity, logins, sudo and privilege escalations. It is among the most sensitive logs on the system: an attacker who can read it harvests account and timing intelligence, and one who can write it can forge or erase evidence of an intrusion. Restricting it to the syslog owner keeps the authentication trail tamper-resistant and confidential.

What Pavois checks

Pavois checks that the owner of /var/log/secure is syslog, only when the file exists (only_if). It reads the live owner (stat) on the target rather than a default, so a chown from rotation, packaging or a misbehaving service is caught as the effective on-disk state.

only_if { file('/var/log/secure').exist? }
describe command("stat -c %U /var/log/secure 2>/dev/null") do
  its('stdout.strip') { should be_in ['root', 'syslog'] }
end

How to verify it is applied

Confirm the owner with:

stat -c '%U' /var/log/secure

Expected output is syslog.

Inspect & investigate

This file is itself the authentication log. Inspect ownership and content:

ls -l /var/log/secure
tail -n 50 /var/log/secure

The writer is rsyslog (systemctl status rsyslog). Ownership changes can be tracked with grep 'secure' /var/log/audit/audit.log if auditd watches are configured.

Remediation

Pavois's harden plan uses a file resource to set the owner of /var/log/secure to syslog. Run pavois harden apply to enforce it, the Chef engine performs the equivalent of chown syslog /var/log/secure, leaving content and group untouched.

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

commandchown root /var/log/secure 2>/dev/null; true
namelog-owner-var-log-secure
not_ifstat -c %U /var/log/secure 2>/dev/null | grep -qxE 'root|syslog'
path/var/log/secure
resourceexec
pavois harden plan local

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

Impact & precautions

Consequences if misconfigured: wrong ownership exposes sensitive authentication data and lets an attacker forge or erase the security log, defeating accountability.

Precautions before applying: safe on Debian/Ubuntu where rsyslog runs as syslog. Note that /var/log/secure is the RHEL-style name; on Debian/Ubuntu the equivalent is /var/log/auth.log, so the only_if guard usually skips this rule there. Ensure the syslog user exists before applying, and confirm any log-shipping agent does not rely on a different owner.

Standards mapping

StandardReferenceTypeVersionConfidence
CIS6.1.4.1, 6.2.2.1directper OS, see the benchmark tablehigh

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