Verify Permissions on /etc/shells File
Ensures /etc/shells is not writable, executable, setuid/setgid or sticky for group or other, so only root can edit the list of valid login shells.
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
/etc/shells lists the full pathnames of the login shells the system considers valid. It is consulted by chsh, FTP daemons and other programs to decide whether an account may log in interactively. If the file is writable by group or other, an unprivileged user could add an arbitrary program as a 'valid shell', for example to bypass restrictions on accounts limited to /usr/sbin/nologin, or remove a shell to lock out services. setuid/setgid/executable bits have no purpose on this text file. Only root must be able to modify it.
What Pavois checks
Pavois reads the live mode bits of /etc/shells on the target (executable/setuid/setgid/sticky/writable by group and other), the effective permissions in the inode, not a documented baseline. Permissions cannot be hidden behind an include or drop-in. The only_if guard skips the control when the file is absent.
only_if { file('/etc/shells').exist? }
describe file('/etc/shells') do
it { should_not be_executable.by('owner') }
it { should_not be_setuid }
it { should_not be_executable.by('group') }
it { should_not be_writable.by('group') }
it { should_not be_setgid }
it { should_not be_executable.by('other') }
it { should_not be_writable.by('other') }
it { should_not be_sticky }
endHow to verify it is applied
Run stat -c '%A %U %G' /etc/shells. Expected: mode -rw-r--r-- (0644) owned by root root, with no write bit for group/other and no s/t bits. Quick check: find /etc/shells -perm /0133 must return nothing.
Inspect & investigate
Permission changes are not logged by default. Watch the file with auditd: auditctl -w /etc/shells -p wa -k shells, then review with grep 'key="shells"' /var/log/audit/audit.log. Shell changes that read this file (chsh) appear in /var/log/auth.log (Debian/Ubuntu) or /var/log/secure (RHEL). Current mode and ownership: stat /etc/shells.
Remediation
No automated harden plan ships for this rule yet, so it must be applied manually: chown root:root /etc/shells && chmod 0644 /etc/shells. This clears any group/other write and any setuid/setgid/sticky bits while keeping the file world-readable, as programs need to read it.
Pavois applies this with its own harden engine, the plan below, not a shell script:
| mode | 0644 |
|---|---|
| path | /etc/shells |
| resource | file |
pavois harden plan localwhere the target is local, a user@host SSH alias, or a container , Docs
Impact & precautions
Risk if left mis-set: a writable /etc/shells lets a non-root user whitelist an unintended shell and potentially escalate the interactive capabilities of a restricted account, or break FTP/chsh policy. Applying the fix is safe: 0644 root:root is the standard mode. Precaution: keep the read bit for other, chsh, FTP daemons and login tooling must read the list; removing world-read can break shell-change and FTP login checks.
Standards mapping
| Standard | Reference | Type | Version | Confidence |
|---|---|---|---|---|
| ANSSI BP-028 | R50 | direct | 2.0 | high |
| CIS | 7.1.9 | direct | per OS, see the benchmark table | high |
| NIST | AC-3, MP-2 | supporting | 800-53 Rev 5 · 800-171 Rev 2 (pinned) | medium |
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.