Handbook sections▾
Foundations
Understanding the threats to a Linux hostWhy we hardenThe defense principles behind every ruleEffective configuration: the truth no file holdsThe standards Pavois maps toSOCLE control ID modelEvidence & exportsHow the A-E grade is computedWhat a PASS proves: the qualified verdictTrust model for the evidence bundleIs SOCLE just your own norm? (governance & the circularity question)What Pavois covers, and what it doesn'tDomains
Hardening SSHHardening PAMMandatory Access Control (SELinux / AppArmor)Hardening the host firewallHardening sudoFile Permissions & OwnershipMount & filesystem hardeningHardening kernel modulesHardening the kernel & network with sysctlAudit logging with auditdHardening logging with journald and rsyslogHardening systemd servicesPackage hygieneHardening the bootloader (GRUB)Synchronizing timeLogin banners and MOTDControlling cron and at accessHardening the GNOME desktop (dconf)Tooling
Undo a hardening run: restore pointsOperating Pavois: privileges, air-gap, timing, exceptionsRun Pavois in CI (GitHub Actions)Feature status: delivered, partial, roadmapGovernance: licence, versioning, provenance, securityWhy we harden
Last reviewed
A fresh install ships permissive defaults. Hardening shrinks the attack surface and the blast radius of a compromise, and makes a system auditable and reproducible.
Why is a default Linux install insecure?
A distribution image is built for broad compatibility and a smooth first boot, not for security. So a fresh OS install ships permissive defaults: unused services listening on the network, legacy filesystem and protocol kernel modules loadable on demand, weak password policy, no audit trail, world-readable files, no host firewall. Every one is a foothold. The attacker doesn't need a zero-day: the default configuration is the vulnerability, and the same default is replicated identically across every machine you deploy. NIST SP 800-123 makes the point plainly: a server must be configured to a secure baseline because out-of-the-box settings favour usability over security.
Why harden it
Hardening is the deliberate removal of everything you don't need and the tightening of everything you keep. Two things shrink at once:
- Attack surface: fewer running services, fewer loadable modules, fewer enabled features means fewer ways in (NIST CM-7, least functionality).
- Blast radius: when a process is compromised, least privilege, mount restrictions, kernel mitigations and a tight
sudo/audit posture limit how far it spreads and how long it stays hidden.
The cost of NOT hardening is asymmetric: invisible until the incident, then it is the whole machine (lateral movement, exfiltration, persistence) plus the regulatory and reputational fallout. Hardening also makes a system auditable (you can prove, rule by rule, what state it is in) and reproducible (the same secure baseline applies identically to every host, instead of hand-tuned snowflakes that drift apart).
Threat to Pavois control to standard
Every rule answers a concrete threat and carries its norm mappings. Five representative examples:
| Permissive default | Concrete threat | Pavois control | Standard |
|---|---|---|---|
PermitRootLogin yes |
remote brute-force straight to root | ssh-disable-root-login | CIS 5.1.x, ANSSI BP-028 R33, STIG |
passwordless sudo, no use_pty |
one cracked user becomes root, session hijack | sudo rules | CIS 5.2.x, ANSSI BP-028 R39 |
| ASLR off, ICMP redirects accepted | reliable exploits, on-path traffic redirection | sysctl rules | CIS 3.x, NIST SC-7, ANSSI BP-028 R8 |
no audit trail (auditd off) |
privileged actions are unattributable | auditd rules | CIS 4.1.x, NIST AU-2, ANSSI BP-028 R73 |
| world-writable file, stray SUID | local privilege escalation, config injection | permissions rules | CIS 6.1.x, ANSSI BP-028 R50 |
The defense principles behind every rule
Every Pavois rule traces to a small set of defense principles: least privilege, attack-surface reduction, defense in depth, secure defaults, accountability and reproducibility. The standards encode the same ideas: NIST 800-53 CM-6 (configuration settings) and CM-7 (least functionality), ANSSI BP-028, and the CIS Benchmarks.
What Pavois audits, and how to see your own posture
Pavois checks this surface against the effective configuration, what the kernel and daemons have actually resolved at runtime, not the files on disk. It reads sysctl -a, systemctl show, sshd -T, loaded-module state and the package database, so it sees Includes, drop-ins and runtime overrides a file-based scan (OVAL/oscap) misses, avoiding false negatives and false positives. One command grades the host and maps every result to its norm chapters:
pavois scan local --profile profiles/linux/debian12 --standard cis --sudo # A-E grade + per-rule, mapped to CIS/ANSSI/NIST/STIGSee exactly what is covered and what is not, and browse the full rule base. Hardening becomes a scored, filterable, reproducible report rather than a checklist.
FAQ
Is hardening the same as a hardening checklist? No. A checklist is a list of steps; a baseline is the measurable end-state you can verify and reproduce. Pavois audits the baseline (the effective state), so you prove compliance rather than trust that a script ran.
Does hardening break things? It can, if applied blindly: a noexec /tmp can break package upgrades, an over-tight sysctl can break a router. That is why each domain page documents exceptions, and why you test in staging before enforcing.
Where do I start? With the highest-impact, lowest-risk wins: disable root SSH, enforce sudo password and use_pty, turn on auditd, set the kernel sysctl mitigations, lock file permissions. The coverage page shows where Pavois is deep.