sudo, A Policy Checked Before It Lands, Refusals Proven

A sudo policy on EL 10 as a drop-in that visudo checks before it lands, with commands written out with their arguments. The live test runs the allowed command without a password and is refused three ways: another subcommand, the same command with a different argument, and a user outside the group. Both appear in sudo's own log. Original role, live-tested on Rocky Linux 10.

ansibleSecurity & Secrets

Verification

Live-tested

Really deployed to a container sandbox, proven idempotent (a second run changes nothing), verified against the role’s assertions, then torn down.

Conformance

  • Static validation (yamllint · ansible-lint)

Provenance

  • SHA-256 checksum
  • Signature (pending)

Functional

  • Live-tested - applied, verified, destroyed

Last verified 2026-09-26 · podman 4.9.3 · ansible 2.21.4 · how we verify

Cite it in your README

badge · attribution

Paste this beside the module in the repository that uses it. The badge is rendered from this artifact's verification record, so it reads live-tested because the record says so, and the link lands on this page.

README.md, GitLab, Gitea
[![IaC Bazaar: live-tested](https://www.iac-bazaar.com/api/artifacts/ansible-sudoers-policy/badge)](https://www.iac-bazaar.com/catalog/ansible-sudoers-policy?utm_source=syndication&utm_medium=readme&utm_campaign=artifact)

Ansible role 1.0.0, live-tested on IaC Bazaar: [sudo, A Policy Checked Before It Lands, Refusals Proven](https://www.iac-bazaar.com/catalog/ansible-sudoers-policy?utm_source=syndication&utm_medium=readme&utm_campaign=artifact)

```yaml
# sudo, A Policy Checked Before It Lands, Refusals Proven: https://www.iac-bazaar.com/catalog/ansible-sudoers-policy (download from your IaC Bazaar account)
```

Preview:IaC Bazaar: live-tested

Documentation

sudoers-policy

Who may run what, as a file sudo will accept. The role writes one drop-in under /etc/sudoers.d, checked by visudo against the rendered candidate before it lands, with the mode and ownership sudo demands. Commands are written with their arguments, so the policy grants exactly what it says.

No download, and no version to pin. sudo is part of EL 10, so the role installs it by name and takes what the distribution ships. What the role owns is the policy and the proof that the host obeys it - in both directions, which for an access rule is the only test worth having.

Nothing to reload. sudo reads the policy on every invocation, so there is no service to restart and no window in which the old policy is still in force. That is also why this role has no handlers at all.

The mode is function, not hygiene, and only visudo -c sees it. A drop-in left at 0644 still works - sudo reads it and the allowed command runs - while visudo -c reports "bad permissions, should be mode 0440". A file owned by anyone but root is worse: sudo ignores the policy and falls back to asking for a password. The verify therefore asserts both the behaviour and visudo -c, because either one alone passes a host whose policy is quietly broken.

requiretty is not set. With it, every automated caller fails with "you must have a tty" - including Ansible, and including this role's own live test. It is a common hardening recommendation and it breaks the thing it is applied to.

sudo -l exits 0 for a user with no rules at all, so the live test reads its output rather than its exit code.

A refused command says "a password is required", not "not allowed". Because every rule here is NOPASSWD and the policy carries no blanket !authenticate, sudo tries to authenticate a command outside the list before deciding it is not permitted - so under sudo -n the message names the password, not the policy. Adding !authenticate would make the message accurate and would also make any password-requiring rule added later silently passwordless, which is the worse trade. The live test therefore reads the OUTCOME rather than the message: the refused command produces no output at all.

License

Commercial - IaC Bazaar EULA. (c) IaC Bazaar.

Usage code & full reference need an account

The complete copy-paste usage, the full input/output reference, and operational notes are free with an account - shown here and bundled in the download. Sign in and this section fills in.

  • Variables
  • Test

Related modules

Live-tested

ansible-aide

AIDE from AppStream on EL 10: a watched tree, a baseline database built once, and the oneshot unit and timer the package does not ship. The live test passes on an unchanged host, FAILS when a file appears inside a watched path and names it, ignores one inside an excluded path, and passes again once the change is gone. Original role, live-tested on Rocky Linux 10.

View module
Live-tested

ansible-authelia

Authelia from the upstream release (sha256-verified) as a hardened system service on loopback with file users and sqlite; its secrets are generated once on the host and reach the service as AUTHELIA_*_FILE variables. The live test hashes a password with Authelia's hasher, logs in, sees a wrong password refused and an anonymous visitor sent to the portal. Original role, live-tested on Rocky 10.

View module
Live-tested

ansible-bandit

bandit on EL 10 from PyPI into a venv of its own with a link in the PATH; the live test runs pip check, then scans a module that passes a string to subprocess.call with shell=True (B602, High, exit 1) and a clean module (exit 0). Pinned. Original role, live-tested on Rocky Linux 10.

View module
Live-tested

ansible-base-hardening

An SSH hardening drop-in sshd reads back: root login and password authentication off, MaxAuthTries 4, idle timeouts. A sysctl security profile under /etc/sysctl.d that a boot applies, and chrony installed with the distribution preset enabling it. The evidence is sshd's own effective configuration, read with sshd -T on Rocky Linux 10.

View module
Live-tested

ansible-boundary

boundary on EL 10 from releases.hashicorp.com; SHA256SUMS is signature-checked against HashiCorp's key before get_url trusts it, the live test re-checks both, then runs authenticate against a dead address ('connection refused') and database init with a throwaway config (parsed, root key loaded, then the database refused). Pinned. Original role, live-tested on Rocky Linux 10.

View module
Live-tested

ansible-dockle

dockle on EL 10 from the GitHub release; get_url refuses it unless its SHA-256 is in the vendor's checksums file, and the live test re-checks it, then scans a one-layer image whose config names no user, expecting CIS-DI-0001 in the output, exit code 1 with --exit-level warn, and the warning counted in the JSON form. Pinned. Original role, live-tested on Rocky Linux 10.

View module