Direct root Logins Not Allowed
Ensures /etc/securetty is empty so root cannot log in directly on any console; admins must authenticate then escalate via su/sudo.
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
When users can log in directly as root on consoles and terminals, all administrative actions collapse into one shared, anonymous identity, you cannot tell who did what. The secure model is: each admin authenticates as themselves, then escalates with su/sudo, which produces an accountable, multi-factor-capable, per-command audit trail. The /etc/securetty file lists the TTYs on which root may log in; an empty file means no terminal allows a direct root login. This control is required for FISMA Low and Moderate baselines.
What Pavois checks
Pavois verifies that /etc/securetty exists but holds no entries (zero size). An empty securetty is the effective signal consulted by pam_securetty.so at login time: PAM denies a direct root login on any TTY that is not listed, and an empty list denies them all.
describe command('[ -s /etc/securetty ] && echo ko || echo ok') do
its('stdout.strip') { should eq 'ok' }
endHow to verify it is applied
Confirm the file is empty:
[ -s /etc/securetty ] && echo populated || echo empty, expected output is empty.wc -l /etc/securetty, expected0 /etc/securetty. A root console login attempt should then be rejected withLogin incorrecteven with the correct password.
Inspect & investigate
Login attempts are recorded by the auth stack:
grep -E 'securetty|root' /var/log/auth.log(Debian/Ubuntu) //var/log/secure(RHEL), showspam_securetty(login:auth): access denied: tty 'ttyN'when a direct root login is correctly blocked.journalctl -t login -t sshdcorrelates console and SSH attempts.
Remediation
No automated harden plan is defined for this rule yet, so it must be applied manually: empty the file with : > /etc/securetty (or remove all its lines) while keeping the file present so pam_securetty.so keeps denying root. Note this governs console/TTY logins; root logins over SSH are governed separately by PermitRootLogin.
Pavois applies this with its own harden engine, the plan below, not a shell script:
| command | : > /etc/securetty |
|---|---|
| name | empty-securetty |
| not_if | test ! -s /etc/securetty |
| resource | exec |
pavois harden plan localwhere the target is local, a user@host SSH alias, or a container , Docs
Impact & precautions
Risk if not applied: shared anonymous root logins erase accountability and remove a layer of authentication.
Precautions before applying: make sure at least one non-root account can reach root via working sudo/su before you remove direct root access, otherwise an admin with no other path is locked out of privileged operations. Keep a privileged session open during the change, and remember single-user/rescue mode still lets you recover the console. SSH root access must be disabled separately.
Standards mapping
| Standard | Reference | Type | Version | Confidence |
|---|---|---|---|---|
| ANSSI BP-028 | R33 | direct | 2.0 | high |
| CIS | 8.6.1, 5.4.2.4 | direct | per OS, see the benchmark table | high |
| NIST | 3.1.1, CM-6(a), IA-2 | supporting | 800-53 Rev 5 · 800-171 Rev 2 (pinned) | medium |
| PCI DSS | 8.6.1 | supporting | 4.0.1 | 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.