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, securitySOCLE control ID model
Last reviewed
Every Pavois control carries a stable SOCLE identifier, SOCLE-<DOMAIN>-<FAMILY>-<NUMBER>. How to read it, the real domains and families, and the stability rules that let you cite it.
The format
Pavois is the executable Linux profile of SOCLE, an open hardening reference. Every control carries a stable SOCLE identifier:
SOCLE-<DOMAIN>-<FAMILY>-<NUMBER>For example SOCLE-CLD-SSH-007, the id of ssh-disable-root-login:
SOCLE: the reference namespace.CLD: the SOCLE domain (host posture).SSH: the technical family inside the domain.007: a stable number within the family.
The domains and families
Pavois audits servers, so its 789 controls live under two SOCLE domains. The real families:
| Domain | Scope | Families |
|---|---|---|
CLD |
host posture | IAM (accounts), GEN (general), KRN (kernel/sysctl), FSP (file permissions), MNT (mounts), MOD (modules), NET (network), BOOT (bootloader), PKG (packages), SSH, SYS (systemd/services) |
RUN |
runtime & observability | AUD (audit), LOG (logging), SVC (services), NTP (time) |
The largest families are FSP (214 controls), PKG (114) and KRN (81), which mirrors where hardening surface actually concentrates.
Why it matters
The SOCLE id is what makes a control citable, like CIS 5.2.1 or NIST AC-3, but neutral and versioned. One Pavois control maps to many external standards at once; the SOCLE id is the single handle that does not change when CIS renumbers or ANSSI revises its guide. It is rendered on every rule fiche and exported in the OSCAL catalog, so a ticket, a policy or an audit report resolves to the same check years later.
Stability rules
- An id is assigned once and never reused.
- A rule that is edited keeps its id as long as the meaning of the control is unchanged.
- A rule that is removed or replaced is marked deprecated; its number is retired, not recycled. So if
SOCLE-CLD-SSH-007were ever superseded, a new check would get the next free number (SOCLE-CLD-SSH-034), and-007would never point at a different control. - New controls append to the end of their family.
These rules let an audit report, a ticket or a policy reference a Pavois control years later and still resolve to the same check.
FAQ
Where does a control's SOCLE id live? In the source of truth (docs/reference/rules.yml, the socle: field), rendered on each rule fiche and exported in the OSCAL catalog. It is generated, not hand-typed, so it stays consistent.
Why not just use the CIS or NIST number? Because one control maps to several standards at once, and those numbers change between releases. The SOCLE id is the one neutral, stable handle across all of them.
What do CLD and RUN mean? CLD is host posture (the static configuration: SSH, kernel, packages, permissions, accounts). RUN is runtime and observability (audit, logging, services, time), the controls about what the running system records and runs.