Verify Ownership of Files in /var/log/sssd
Ensure every file under /var/log/sssd is owned by sssd or root and by no other user.
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 holds debug logs for the System Security Services Daemon (SSSD), which mediates authentication against LDAP/Active Directory and can record account and credential details. Files must be owned only by sssd or root; any other owner could read or tamper with authentication logs, undermining the audit trail.
What Pavois checks
Pavois runs find -P /var/log/sssd -type f ! -user sssd ! -user root (only if the directory exists) and expects no output, any file owned by something other than sssd or root is a finding. It checks the real inodes' effective ownership, catching files re-owned at runtime that a static config check would miss.
only_if { command('test -d /var/log/sssd').exit_status.zero? }
describe command('timeout 60 find -P /var/log/sssd -type f ! -user sssd ! -user 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 find -P /var/log/sssd -type f ! -user sssd ! -user root, it should print nothing. Any printed line is a wrongly-owned SSSD log file to fix.
Inspect & investigate
List offending files with find -P /var/log/sssd -type f ! -user sssd ! -user root -printf '%u %p\n'. SSSD's own logs live here (e.g. sssd_*.log); the daemon's service events can be reviewed with journalctl -u sssd.
Remediation
There is no automated harden plan for this rule. Apply it manually after review: re-own offenders to root or sssd, e.g. find -P /var/log/sssd -type f ! -user sssd ! -user root -exec chown root {} +. (Only relevant where SSSD is installed.)
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
What can break: very little, SSSD writes its logs as its own service user and is unaffected by fixing stray owners. Precautions: prefer re-owning to sssd (the daemon's user) rather than root so SSSD can keep appending; review each file first, as an unexpected owner may signal a debugging session left running with elevated logging. Where SSSD is not installed the directory is absent and the rule is skipped (only_if).
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.