Verify Grouponwership of Files in /var/log/sssd
Ensures every file under /var/log/sssd is group-owned by sssd or root (when the directory exists).
Checked against a path’s metadata, mode, owner, group, SUID/SGID.
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 /var/log/sssd directory contains debug logs for the System Security Services Daemon (SSSD), which mediates authentication against LDAP, Active Directory or Kerberos. These logs can expose usernames, group memberships, domain topology and authentication errors. If they are group-owned by an unexpected group, members could read this sensitive identity data or tamper with the logs. Restricting group ownership to sssd or root keeps it accessible only to authorized personnel.
What Pavois checks
Guarded by only_if test -d /var/log/sssd so it is skipped where SSSD is not deployed. Pavois then runs find -P /var/log/sssd -type f ! -group sssd ! -group root and expects empty output. Reading the actual group on each inode catches debug logs created at runtime that a config-file review would not see.
only_if { command('test -d /var/log/sssd').exit_status.zero? }
describe command('timeout 60 find -P /var/log/sssd -type f ! -group sssd ! -group root -print -quit 2>/dev/null') do
its('exit_status') { should_not cmp 124 } # timeout killed the scan: no evidence, not a pass
its('stdout.strip') { should eq '' }
endHow to verify it is applied
Run sudo find /var/log/sssd -type f ! -group sssd ! -group root 2>/dev/null. Expected output: empty. Inspect any returned file with ls -l <path> to see its wrong group.
Inspect & investigate
List offending files with their group via find /var/log/sssd -type f -printf '%g %p\n'. There is no daemon log for ownership; verify directly with stat -c '%G %n' /var/log/sssd/*.
Remediation
No automated harden plan is provided. Fix it manually with chgrp sssd <file> for each offending file, e.g. find /var/log/sssd -type f ! -group sssd ! -group root -exec chgrp sssd {} +.
Pavois applies this with its own harden engine, the plan below, not a shell script:
| command | # Set root ownership recursively under the sssd log dir (only if it exists): [ -d /var/log/sssd ] && find /var/log/sssd -print0 | xargs -0 -r chown root: || echo 'no /var/log/sssd' |
|---|---|
| reason | recursive ownership fix under /var/log/sssd, verify the service is present and review |
| resource | manual |
pavois harden plan localwhere the target is local, a user@host SSH alias, or a container , Docs
Impact & precautions
Changing the group of SSSD logs is low-risk and has no effect where SSSD is absent (the check is skipped). Set the sssd group so the daemon retains write access to its debug logs; an incorrect group could prevent SSSD from logging. A simple chgrp does not affect authentication itself, only the log files.
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.