Ensure Only Users Logged In To Real tty Can Execute Sudo - sudo requiretty
Enable the Defaults requiretty option so sudo can only be invoked from a real terminal (tty), not from a script, cron job or daemon without one.
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
Requiring a real tty restricts the contexts in which sudo may be used and reduces the attack surface. Without requiretty, a compromised web service, daemon or background process could call sudo non-interactively; it also limits the impact of session-hijacking tricks where the attacker has no controlling terminal. Forcing an interactive tty ties privilege escalation to a genuine, attributable login session.
What Pavois checks
Pavois greps the active sudoers tree, /etc/sudoers and every file under /etc/sudoers.d/, for an uncommented Defaults ... requiretty. Because sudo merges its policy from the main file plus all drop-ins, scanning the whole tree reflects the effective policy rather than a single file a later drop-in could override.
describe command('grep -rqE \'^[^#]*Defaults[^#]*\brequiretty\b\' /etc/sudoers /etc/sudoers.d/ 2>/dev/null && echo ok || echo ko') do
its('stdout.strip') { should eq 'ok' }
endHow to verify it is applied
Run sudo grep -rE '^[^#]*Defaults.*requiretty' /etc/sudoers /etc/sudoers.d/. A matching, uncommented line confirms the option is active. To test, a sudo call with no tty (e.g. ssh host 'sudo id' without -t) should now fail with sorry, you must have a tty to run sudo.
Inspect & investigate
sudo invocations and refusals are logged to /var/log/auth.log (Debian/Ubuntu) or /var/log/secure (RHEL), and via journalctl -t sudo. A tty-less attempt is recorded with a requiretty/must have a tty denial, useful to spot scripts or services that were silently using sudo.
Remediation
Pavois's harden plan writes a file resource at /etc/sudoers.d/99-Pavois-requiretty containing Defaults requiretty, owned root:root with mode 0440, validated with visudo -cf before activation. Apply it with pavois harden apply. The dedicated drop-in keeps the change isolated and reversible.
Pavois applies this with its own harden engine, the plan below, not a shell script:
| content | Defaults requiretty |
|---|---|
| group | root |
| mode | 0440 |
| owner | root |
| path | /etc/sudoers.d/99-pavois-requiretty |
| resource | file |
| verify | visudo -cf %{path} |
pavois harden plan localwhere the target is local, a user@host SSH alias, or a container , Docs
Impact & precautions
requiretty breaks non-interactive sudo: cron jobs, CI pipelines, configuration-management agents (Ansible, Chef) and ssh host 'sudo ...' calls without a pseudo-tty will fail. Before applying, audit such callers, switch SSH automation to ssh -t, set Ansible's pipelining/pty appropriately, or grant tty-less paths a scoped exemption with a matching Defaults!/command !requiretty rule. The drop-in is validated by visudo before activation, so it cannot corrupt sudoers; verify your automation right after applying.
Standards mapping
| Standard | Reference | Type | Version | Confidence |
|---|---|---|---|---|
| ANSSI BP-028 | R39 | direct | 2.0 | 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.