Sections du handbook▾
Fondations
Comprendre les menaces qui pèsent sur un hôte LinuxPourquoi on durcitLes principes de défense derrière chaque règleConfiguration effective : la vérité qu'aucun fichier ne contientLes normes que Pavois cartographieModèle d'identifiant de contrôle SOCLEPreuves & exportsComment la note A-E est calculéeCe qu'un PASS prouve : le verdict qualifiéModèle de confiance du bundle de preuveSOCLE, n'est-ce pas votre propre norme ? (gouvernance & la question de la circularité)Ce que Pavois couvre, et ce qu'il ne couvre pasDomaines
Durcir SSHDurcir PAMContrôle d'accès obligatoire (SELinux / AppArmor)Durcir le pare-feu localDurcir sudoPermissions et propriété des fichiersDurcir les montages et le système de fichiersDurcir les modules noyauDurcir le noyau et le réseau avec sysctlJournalisation d'audit avec auditdDurcir la journalisation avec journald et rsyslogDurcir les services systemdHygiène des paquetsDurcir le chargeur d'amorçage (GRUB)Synchroniser l'heureBannières de connexion et MOTDContrôler l'accès à cron et atDurcir le bureau GNOME (dconf)Outillage
Annuler un durcissement : les points de restaurationExploiter Pavois : privilèges, air-gap, durée, dérogationsLancer Pavois en CI (GitHub Actions)État des fonctionnalités : livré, partiel, roadmapGouvernance : licence, versionnement, provenance, sécuritéCe qu'un PASS prouve : le verdict qualifié
Revu le
La plupart des scanners répondent par un bit : réussite ou échec. Pavois qualifie chaque PASS sur deux axes, quelle preuve il a lue et s'il survit à un redémarrage, et le verdict alimente la note A-E.
La plupart des scanners répondent à un contrôle par un bit : réussite ou échec. Ce bit masque la question qui compte vraiment sur un système en fonctionnement : que prouve ce PASS, et sera-t-il encore vrai après un redémarrage ? Pavois le rend explicite. Chaque contrôle porte un verdict qualifié bâti sur deux axes indépendants, et le verdict alimente la note A-E.
Deux axes, pas un
Type de preuve : ce que la vérification lit réellement (détaillé dans preuves et exports). Pavois utilise quatre types :
| Type de preuve | Ce qu'un PASS prouve |
|---|---|
effective-runtime |
la valeur résolue dans le système en fonctionnement (sshd -T, sysctl, auditctl -l) |
persistent-config |
le réglage est écrit là où il survit à un redémarrage |
inventory-state |
un paquet ou composant est installé ou absent (dpkg/rpm) |
filesystem-state |
le mode, le propriétaire ou le contenu d'un fichier sur disque |
Survivabilité au redémarrage (reboot_survivable) : un PASS prouve-t-il un état qui survit à un redémarrage. C'est indépendant du type de preuve : une lecture runtime peut être reboot-proof (la config compilée d'un noyau, sshd -T re-parsant les fichiers de config), tandis qu'une autre est purement vivante (sysctl du noyau en cours, un mount -o remount, une règle chargée par auditctl mais absente du disque). Elle répond : tiendra-t-il encore après un redémarrage ?
Un PASS prouve : trois colonnes
La fiche de chaque contrôle montre ce qu'un PASS établit sur actif maintenant, sur disque et survit au reboot, chacun comme prouvé, non mesuré, ou non applicable. Un sysctl vérifié seulement contre le noyau vivant prouve actif maintenant mais laisse survit au reboot inconnu ; la même vérification qui atteste aussi que la valeur est fixée dans /etc/sysctl.d prouve les trois.
Le plafond de note
Un PASS runtime-only, actif maintenant mais à persistance non prouvée, ne compte pas comme un PASS plein. Il plafonne la note : un hôte dont la conformité repose sur un état purement vivant ne peut décrocher un A net ; la note est affichée runtime-qualifiée (plafonnée à B) jusqu'à preuve de la persistance. Les points restent pilotés par les échecs (un PASS qualifié n'ajoute jamais d'échec), donc le plafond est honnête, pas punitif : il refuse d'attribuer un A à une posture qui régresserait au prochain démarrage. En --format json, cela se voit via runtime_qualified et qualified_passes :
{
"grade": "B",
"points": 100,
"runtime_qualified": true,
"qualified_passes": 7,
"passed": 150,
"total": 150
}Ici les points valent 100 (aucun contrôle n'a échoué), un A sur la seule arithmétique, mais 7 PASS reposent sur une persistance non prouvée, donc la lettre est plafonnée à B tandis que les points restent à 100.
Comment la persistance est réellement prouvée
Pavois n'en fait pas une simple réserve, il intègre la preuve de persistance dans la vérification elle-même partout où il existe une source de vérité propre :
- sysctl atteste la valeur vivante et qu'elle est fixée dans un fichier de config sysctl.
- les options de montage attestent l'option vivante et une entrée dans
/etc/fstabou une unité systemd.mount. - la ligne de commande noyau atteste
/proc/cmdlineet le paramètre dans la config du bootloader. - les règles d'audit attestent que la règle est chargée et présente dans
/etc/audit/rules.d. - les modules noyau sont reboot-proof par construction (
be_disabledlit la config persistantemodprobe.d).
Quelques contrôles restent légitimement runtime-only (un mode MAC via getenforce, l'is-active vivant d'un service, le pare-feu vivant) sans source persistante propre à intégrer. Ils restent runtime-qualifiés, honnêtement.
Reboot-proven
La preuve la plus forte est empirique. pavois harden apply --reboot --scan converge les correctifs, redémarre la cible, attend son retour, et re-scanne : un PASS dans ce rapport a donc survécu à un vrai redémarrage. Les contrôles qui ne prennent effet qu'après un démarrage (un paramètre de ligne de commande noyau, un jeu de règles d'audit immuable) sont alors reboot-proven, pas seulement affirmés. C'est la barre à laquelle un A net est tenu.
FAQ
Que prouve réellement un PASS ? Exactement ce que disent son type de preuve et sa survivabilité au redémarrage : un PASS effective-runtime prouve que la valeur est en vigueur maintenant ; seule une vérification qui lit aussi la source persistante (ou un re-scan après redémarrage) prouve qu'elle survit à un redémarrage.
Pourquoi mon A a-t-il été plafonné à B ? Parce que certains PASS sont runtime-only à persistance non prouvée. La note est affichée runtime-qualifiée ; prouvez la persistance (ou re-scannez après un redémarrage avec --reboot --scan) pour lever le plafond.
Quels contrôles ne peuvent jamais être reboot-proven sans redémarrage ? Ceux qui sont vraiment purement vivants : le mode SELinux/AppArmor, l'is-active d'un service, le pare-feu en cours. Pavois les marque runtime-qualifiés plutôt que de prétendre que l'état vivant est persistant.