Handbook sections

The defense principles behind every rule

Last reviewed

Every Pavois rule is one principle made concrete: defense in depth, least privilege, attack-surface reduction, fail-safe defaults, separation of duties, accountability.

Why principles, not just a checklist?

A hardening benchmark looks like a long, flat checklist: hundreds of settings with no obvious logic. Treated that way, it becomes a box-ticking exercise: rules get waived because nobody remembers why they exist, exceptions pile up, and the posture silently rots. The real threat is misunderstanding. An attacker needs only one forgotten setting (a permissive default, a privilege never dropped, an action nobody logged) to turn a small foothold into full compromise. The checklist is not the point; the principles behind it are. Most of them were named in 1975 by Saltzer and Schroeder and still hold.

Why it matters

Principles are what make a benchmark survivable in production. When you understand that a rule serves least privilege or attack-surface reduction, you can judge an exception on its merits instead of waiving it blindly, and you can extend the policy to systems the benchmark never covered. Six principles underpin essentially every Linux hardening rule, and each maps to concrete, auditable configuration.

Principle to Pavois control to standard

Principle Concrete Pavois controls Standard family
Defense in depth sysctl + kernel modules + firewall layered NIST SC-7, CIS 3/4, ANSSI BP-028 R8
Least privilege no root SSH, sudo scoping, no extra UID-0, umask NIST AC-6, ANSSI BP-028 R39
Attack-surface reduction remove packages/services, blacklist modules NIST CM-7, CIS 1/2, ANSSI BP-028 R67
Fail-safe defaults faillock, pwquality, audit fail-closed, permissions NIST AC-7/IA-5, CIS 5, ANSSI BP-028 R31
Separation of duties named sudo, auditd immutability NIST AC-5/AU-9, ANSSI BP-028 R73
Accountability auditd, journald, banners NIST AU-2/AU-12, ANSSI BP-028 R71

The six principles, applied

  • Defense in depth: never rely on a single control. The kernel stack is hardened with sysctl and unused protocols are disabled and a firewall is present, so the failure of one layer is caught by the next.
  • Least privilege: every identity gets the minimum it needs. No direct root login, no extra UID-0 accounts, tight sudo scoping, restrictive umask, root-owned system files.
  • Attack-surface reduction: what does not run cannot be exploited. Remove legacy services (telnet, rsh), unload unused kernel modules, strip optional sshd features.
  • Fail-safe / secure defaults: the safe state must be the default state. Lockout after failed logins (faillock), strong pwquality, audit rules that fail closed on disk error, conservative permissions out of the box.
  • Separation of duties: no single account is both actor and auditor. Named users escalate through sudo (attributable), and the audit trail is immutable so the watched cannot erase it.
  • Accountability: if it is not recorded, it did not happen. auditd captures privileged actions and DAC changes, journald persists logs, banners assert the policy.

Anti-patterns that quietly break a principle

  • Blanket NOPASSWD: ALL sudo for convenience destroys least privilege and accountability at once. Scope it to the exact command.
  • chmod -R 777 to fix a permission error trades a five-minute debug for a permanent least-privilege hole. Find the one wrong bit instead.
  • Disabling the firewall or auditd to debug, then forgetting turns defense in depth into a single point of failure. Re-enable in the same change.
  • Logging only locally lets the same root that was compromised wipe the evidence. Ship logs off-box (accountability).
  • Waiving a rule with no recorded reason is how a benchmark rots: the next reviewer cannot tell a deliberate exception from an oversight.

What Pavois audits

Pavois checks the effective configuration, not just the files on disk, the angle that sets it apart from file-probed OVAL/oscap checks. Each principle becomes concrete checks: sshd -T for resolved daemon settings, sysctl -a for the live kernel stack, systemctl show for unit state, plus auditd/journald, faillock, pwquality, sudo, umask, account databases and file ownership. Because it reads resolved state, it sees the Includes and drop-ins a file scan misses, so a rule passes only when the principle is actually in force.

FAQ

Why learn the principles if I just run the benchmark? Because a benchmark cannot cover every system or every exception. Knowing the principle lets you judge a waiver and extend the policy where the checklist is silent.

Where do these principles come from? The classics (least privilege, fail-safe defaults, separation of privilege) were formalized by Saltzer and Schroeder in 1975; the standards (NIST 800-53 AC/AU/CM/SC, ANSSI BP-028, CIS) encode them as concrete controls.

Which principle matters most? They compose: least privilege limits the blast radius, defense in depth ensures one failure is not fatal, accountability lets you detect and reconstruct. A gap in any one is where the attacker goes.