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, securityWhat Pavois covers, and what it doesn't
Last reviewed
A reference is trusted for what it admits it cannot do. The honest map: the host-hardening domains Pavois audits in depth, the ones still thin, and what is out of scope by design.
Pavois audits the effective configuration of a running Linux host: server posture, not the whole DevSecOps surface. Being explicit about the edges is the point of this page.
Audited in depth
Across 9 OS families, 789 controls, the well-covered domains. Each links to its rules:
| Domain | Controls | Notes |
|---|---|---|
| File ownership and permissions | ~200 | owners, modes, SUID/SGID |
| Packages | ~114 | unwanted absent, required present |
| Kernel (sysctl / build / modules / cmdline) | ~170 | running values, compiled config, blacklists, boot params |
| systemd services | ~40 | resolved unit state |
| Mounts | ~38 | effective mount options |
| SSH | ~33 | from sshd -T, not the file |
| Accounts / PAM / pwquality / faillock / login.defs / sudo | ~55 | password policy, lockout, privilege |
| Audit (auditd + rules) | ~37 | daemon + loaded rules |
| GNOME / dconf, banners, cron | ~30 | desktop and access policy |
Coverage by OS and by standard
By OS: the same neutral controls are rendered for 9 families: debian12, debian13, ubuntu2204, ubuntu2404, ubuntu2604, rhel8, rhel9, rhel10, fedora (each pinned to its CIS benchmark version, except the three that have none and inherit a sibling's, see the CIS table). A control only applies where the OS supports it; the rest read not-applicable.
By standard: every control carries its mappings, so one scan answers CIS (L1/L2), ANSSI BP-028 (R-rules, minimal..high), NIST 800-53/171, PCI-DSS and STIG at once. See the standards for how a mapping is read, and export the baseline as OSCAL for your GRC tool.
Partial and shallow: real but not deep yet
These exist but are not yet deep enough to lean on alone. Partial means audited beyond mere presence, with named gaps; shallow means presence or default only. The rules explorer tags every control in these domains with the matching badge.
| Area | Depth | State | What's missing |
|---|---|---|---|
| Firewall | shallow | 2 controls | only presence/default-deny; no ruleset audit (nft/ufw/firewalld zones) |
| Time synchronization | shallow | 1 control | sync present; no source/drift policy |
| Logging (journald / forwarding) | partial | ~4 controls | storage/forward flags only; no remote-log integrity |
| MAC (SELinux / AppArmor) | partial | status-level | enforcing/loaded checked; custom policy, booleans, unconfined services, AVC audit not covered |
Out of scope by design
Pavois is a host-config auditor. These are deliberately not its job, and naming them keeps the claim honest:
- Container runtime hardening (Docker/containerd/K8s node and workload posture): a different effective surface.
- Immutable / atomic hosts (ostree, image-based): the apply model and several checks assume a mutable host.
- Cloud images and control plane (golden-image pipelines, IAM, CSPM): SOCLE's CLD-cloud domains, not this Linux profile.
- Secrets management and rotation: presence of obvious secrets is touched; lifecycle/rotation is not.
- Application layer (web-server, DB, app config depth beyond presence).
- Custom kernels: kconfig checks assume a distro kernel layout.
- Network devices, Windows, macOS: out of the Linux-host scope.
How to read a gap
A domain being thin or absent is not a silent pass: it means Pavois makes no claim there. The grade only scores controls that ran (see scoring); it never credits a host for a check Pavois doesn't have. If a control matters to you and it's missing, that's a contribution, not a blind spot we hide: the rule base is open and cross-validated.
FAQ
Does a missing domain mean my host passed it? No. Pavois makes no claim where it has no control; the grade only scores checks that ran. A gap is honesty, not a silent pass.
Which domains should I not rely on Pavois alone for? Firewall (presence only), time sync (presence only), remote-log integrity, and MAC beyond enforcing/loaded (no custom policy, booleans or AVC audit yet). Each is badged in the rules explorer.
Does coverage differ by OS? The control set is neutral but a control only applies where the OS supports it; mappings are pinned per benchmark version across the 9 families, and inapplicable controls read not-applicable.