Verify Permissions of Files in /var/log/sssd
Ensure the /var/log/sssd directory is not writable by group or other, so SSSD debug logs can only be modified by privileged accounts.
Checked against the content of a persistent configuration file, the source of truth that survives reboots.
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/sssd holds the debug logs of the System Security Services Daemon, which mediates authentication against LDAP/AD/Kerberos. These logs can expose usernames, domain topology and authentication errors, and a writable directory would let an attacker delete or forge entries to hide a credential attack. Locking it to root protects both the confidentiality of identity data and the integrity of the authentication audit trail.
What Pavois checks
Pavois reads the live inode of /var/log/sssd and asserts it is writable by neither group nor other. Inspecting the real directory catches drift introduced by a manual chmod, a package update or a restored backup, the effective mode is what an attacker could actually exploit, regardless of what sssd.conf or the package intended.
only_if { file('/var/log/sssd').exist? }
describe file('/var/log/sssd') do
it { should_not be_writable.by('group') }
it { should_not be_writable.by('other') }
endHow to verify it is applied
Run stat -c '%A %U:%G' /var/log/sssd. Expect drwxr-x--- (0750) owned by root:root, no write bit for group or other.
Inspect & investigate
The directory holds SSSD's own logs (sssd.log, domain and nss/pam responder logs); inspect with ls -l /var/log/sssd/ and tail the relevant file, or use journalctl -u sssd. To detect permission tampering, add auditctl -w /var/log/sssd -p wa and review /var/log/audit/audit.log.
Remediation
Pavois's harden plan applies a directory resource on /var/log/sssd, setting owner root, group root and mode 0750, which removes all group/other write (and other read) access. Apply it with pavois harden apply.
Pavois applies this with its own harden engine, the plan below, not a shell script:
| group | root |
|---|---|
| mode | 0750 |
| owner | root |
| path | /var/log/sssd |
| resource | directory |
pavois harden plan localwhere the target is local, a user@host SSH alias, or a container , Docs
Impact & precautions
A writable SSSD log directory lets attackers erase evidence of failed/forged logins or leak directory metadata. Precautions: the sssd daemon runs as root (or the sssd user on some builds) and writes here, so keep ownership/mode aligned with how SSSD was installed, on distros where SSSD runs as a dedicated sssd user you may need group sssd instead of root so the daemon can still write. After applying 0750, restart with systemctl restart sssd and confirm logging still works; if SSSD cannot write, authentication will keep functioning but troubleshooting logs will be lost.
Standards mapping
| Standard | Reference | Type | Version | Confidence |
|---|---|---|---|---|
| CIS | 6.1.4.1, 6.2.2.1 | direct | per OS, see the benchmark table | high |
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.