Detections
Analytics

6.1.3.1 Ensure access to all logfiles has been configured

Information

Log files contain information from many services on the local system, or in the event of a centralized log server, other systems' logs as well.

In general log files are found in /var/log/, although applications can be configured to store logs elsewhere. Should your application store logs in another location, apply the same audit to that location.

It is important that log files have the correct permissions to ensure that sensitive data is protected and that only the appropriate users / groups have access to them.

NOTE: Nessus has provided the target output to assist in reviewing the benchmark to ensure target compliance.

Solution

Log file access is most reliably enforced at the point of creation: if the mechanism that creates each log sets the correct mode and ownership, new and rotated logs are born compliant and the state does not drift back on the next rotation or reboot. Correct the creating mechanism first, then adjust any existing files.

 -

Configure the log-creating mechanisms so new logs are created with restrictive access:

 - For the general system and authentication logs written by rsyslog, set the file creation mode to 0640 or more restrictive (see the recommendation for configuring the rsyslog log file creation mode).
 - systemd journal files are created mode 0640, group systemd-journal by systemd-journald; no change is required.
 - For logs rotated by logrotate, use a create directive with the correct mode and ownership so rotated files retain the restrictive access (see the recommendation for configuring logrotate).

 -

Correct existing files. For each file returned by the Audit, set its mode and ownership to match its class in the table. For a general system or authentication log that is more permissive than 0640, or not owned by root:root, run the following commands to restrict its access and set its ownership:

# chmod u-x,g-wx,o-rwx <file>
# chown root:root <file>

For the other classes, apply the corresponding values instead:

 - Login accounting ( wtmp*, btmp*, lastlog* ) - mode 0664 or more restrictive, group utmp.
 - systemd journal ( *.journal, *.journal~ ) - group systemd-journal.
 - Package-manager logs (files written by the system package manager, e.g. /var/log/apt/, /var/log/dnf.*, /var/log/dnf5.log, /var/log/zypp/ ) - mode 0644 or more restrictive, group root or adm.
 - Cloud or agent logs ( cloud-init.log*, localmessages*, waagent.log* ) - mode 0644 or more restrictive.
 - Service-account logs - keep that account as the owner and group; only remove world and any excess access. Do not force root ownership, as it can break the service that writes the log.

 - Re-run the Audit to confirm no files remain.

Note: Each class's ceiling matches the platform's default creation mode, so a file corrected to its class value stays compliant when the service or logrotate recreates it - provided the creating mechanism in step 1 is set correctly. Applying step 2 without step 1 may allow a sensitive log to be recreated world-readable on the next rotation.

Impact:

Tightening permissions and ownership on files under /var/log/ can disrupt services or tooling that rely on broader access. The remediation is applied per file type and is non-destructive, but capture its output in case a service's logging needs to be reconfigured.

See Also

https://workbench.cisecurity.org/benchmarks/27890

Item Details

Category: ACCESS CONTROL, AUDIT AND ACCOUNTABILITY

References: 800-53|AC-3, 800-53|AU-9, CSCv7|14.6

Plugin: Unix

Control ID: 128d20678ba2c170f52913b44663f5fbd929789ce50555da4678d561630e4f6e