In this lesson, you will learn how to configure your log rotation processes to maintain strict security boundaries and prevent data loss during the archival phase.
The Security Dilemma of Log Rotation
In a hardened environment, log files are sensitive security artifacts. When logrotate triggers, it renames current files and creates new ones. If the security context (like an SELinux label) or ownership permissions are not preserved during this transition, you risk creating a "security gap." A newly rotated log file might inadvertently inherit permissive default permissions, allowing unauthorized users to read sensitive system events before the log-processing tools can ingest them.
Ensuring Integrity During Rotation
To harden this process, you must ensure that logrotate operates with the principle of least privilege while enforcing strict file-system constraints. When defining your log rotation configuration, you must explicitly define the create directive with the exact mode, owner, and group required by your security policy.
Consider this configuration snippet for a sensitive log:
/var/log/app/secure.log {
daily
rotate 7
compress
missingok
# Enforce strict permissions at the moment of creation
create 0600 root root
# Ensure the security context remains intact
sharedscripts
postrotate
/usr/bin/systemctl restart rsyslog > /dev/null 2>&1 || true
endscript
}
By explicitly setting create 0600 root root, you prevent the race condition where a temporary file might be created with insecure permissions. Furthermore, if you are using Mandatory Access Control (MAC), the postrotate script must be authorized to interact with the service being restarted. If the rotation process cannot restore the correct security context or file permissions, the system may fail to write to the new log file, leading to a silent failure where security events are lost entirely.
Preventing Log Loss
Hardening also involves ensuring that the rotation process does not "fail-open." By using the missingok directive, you prevent the utility from halting the entire rotation chain if one file is missing, but you should monitor the rotation logs for such errors. Always verify that your MAC policy allows the logrotate process to rename and create files within the designated audit directories; otherwise, the system will experience a permanent loss of visibility into your security logs.
Key Takeaway: Hardening log rotation requires explicitly defining file permissions at creation and ensuring your MAC policy preserves the security context throughout the renaming process to prevent gaps in your audit trail.