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 que Pavois couvre, et ce qu'il ne couvre pas
Revu le
Une référence inspire confiance par ce qu'elle admet ne pas savoir faire. La carte honnête : les domaines de durcissement hôte que Pavois audite en profondeur, ceux encore minces, et ce qui est hors périmètre par conception.
Pavois audite la configuration effective d'un hôte Linux en exécution : la posture serveur, pas toute la surface DevSecOps. Être explicite sur les bords est tout l'objet de cette page.
Audité en profondeur
Sur 9 familles d'OS, 789 contrôles, les domaines bien couverts. Chacun renvoie à ses règles :
| Domaine | Contrôles | Notes |
|---|---|---|
| Propriété et permissions de fichiers | ~200 | propriétaires, modes, SUID/SGID |
| Paquets | ~114 | indésirables absents, requis présents |
| Noyau (sysctl / build / modules / cmdline) | ~170 | valeurs runtime, config compilée, blacklists, params de boot |
| Services systemd | ~40 | état résolu des unités |
| Montages | ~38 | options de montage effectives |
| SSH | ~33 | depuis sshd -T, pas le fichier |
| Comptes / PAM / pwquality / faillock / login.defs / sudo | ~55 | politique mdp, verrouillage, privilèges |
| Audit (auditd + règles) | ~37 | démon + règles chargées |
| GNOME / dconf, bannières, cron | ~30 | bureau et politique d'accès |
Couverture par OS et par norme
Par OS : les mêmes contrôles neutres sont rendus pour 9 familles : debian12, debian13, ubuntu2204, ubuntu2404, ubuntu2604, rhel8, rhel9, rhel10, fedora (chacune épinglée à sa version de benchmark CIS, sauf les trois qui n'en ont pas et héritent d'un frère, voir le tableau CIS). Un contrôle ne s'applique que là où l'OS le supporte ; le reste est non-applicable.
Par norme : chaque contrôle porte ses correspondances, donc un seul scan répond à CIS (N1/N2), ANSSI BP-028 (règles R, minimal..high), NIST 800-53/171, PCI-DSS et STIG d'un coup. Voir les normes pour la lecture d'un mapping, et exportez la baseline en OSCAL pour votre outil GRC.
Partielle et superficielle : réel mais pas encore profond
Cela existe mais n'est pas encore assez profond pour s'y fier seul. Partielle = audité au-delà de la simple présence, avec des manques nommés ; superficielle = présence ou défaut seulement. L'explorateur de règles marque chaque contrôle de ces domaines avec le badge correspondant.
| Domaine | Profondeur | État | Ce qui manque |
|---|---|---|---|
| Pare-feu | superficielle | 2 contrôles | présence/deny par défaut seulement ; pas d'audit de règles (zones nft/ufw/firewalld) |
| Synchronisation de temps | superficielle | 1 contrôle | sync présente ; pas de politique source/dérive |
| Journalisation (journald / forwarding) | partielle | ~4 contrôles | flags storage/forward seulement ; pas d'intégrité du log distant |
| MAC (SELinux / AppArmor) | partielle | niveau statut | enforcing/chargé vérifiés ; politique custom, booléens, services unconfined, audit AVC non couverts |
Hors périmètre par conception
Pavois est un auditeur de config hôte. Ce qui suit n'est délibérément pas son rôle, et le nommer garde l'affirmation honnête :
- Durcissement runtime des conteneurs (posture nœud et charge Docker/containerd/K8s) : une autre surface effective.
- Hôtes immuables / atomiques (ostree, image-based) : le modèle d'apply et plusieurs checks supposent un hôte mutable.
- Images cloud et plan de contrôle (pipelines d'images, IAM, CSPM) : les domaines CLD-cloud de SOCLE, pas ce profil Linux.
- Gestion et rotation des secrets : la présence de secrets évidents est effleurée ; le cycle de vie / la rotation, non.
- Couche applicative (serveur web, BDD, profondeur de config applicative au-delà de la présence).
- Noyaux custom : les checks kconfig supposent une disposition de noyau distribution.
- Équipements réseau, Windows, macOS : hors du périmètre hôte Linux.
Comment lire un creux
Un domaine mince ou absent n'est pas un PASS silencieux : cela veut dire que Pavois n'y fait aucune affirmation. La note ne score que les contrôles exécutés (voir scoring) ; elle ne crédite jamais un hôte pour un check que Pavois n'a pas. Si un contrôle compte pour vous et qu'il manque, c'est une contribution, pas un angle mort qu'on cache : la base de règles est ouverte et recoupée.
FAQ
Un domaine absent signifie-t-il que mon hôte l'a réussi ? Non. Pavois ne fait aucune affirmation là où il n'a pas de contrôle ; la note ne score que les checks exécutés. Un creux est de l'honnêteté, pas un PASS silencieux.
Pour quels domaines ne pas se fier à Pavois seul ? Pare-feu (présence seulement), synchro de temps (présence seulement), intégrité du log distant, et MAC au-delà de enforcing/chargé (pas encore de politique custom, booléens ni audit AVC). Chacun est badgé dans l'explorateur de règles.
La couverture diffère-t-elle par OS ? Le jeu de contrôles est neutre mais un contrôle ne s'applique que là où l'OS le supporte ; les mappings sont épinglés par version de benchmark sur les 9 familles, et les contrôles inapplicables sont non-applicables.