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éÉtat des fonctionnalités : livré, partiel, roadmap
Revu le
Une carte honnête de chaque promesse de Pavois face à ce qui est livré aujourd’hui, ce qui est partiel et ce qui est sur la roadmap. Aucune promesse sans statut.
Une référence doit être honnête sur ses propres limites. Cette page relie chaque capacité à l’un de trois états : livré (fonctionne aujourd’hui), partiel (fonctionne mais incomplet), roadmap (annoncé, pas encore livré).
Moteur et verdict
| Capacité | Statut | Notes |
|---|---|---|
Audit de config effective (sshd -T, sysctl, systemctl, auditctl) |
livré | la lecture cœur ; la vue résolue, pas un fichier seul |
| Un contrôle, N normes (CIS / ANSSI BP-028 / NIST / PCI-DSS / STIG) | livré | un seul check porte tous ses mappings applicables |
| Note A à E avec plafonds sur échec critique | livré | formule publiée, figée par un test |
| Verdict qualifié (type de preuve + survie au reboot) | livré | matrice « un PASS prouve » par fiche |
| Plafond sur les PASS runtime-only (runtime-qualifié) | livré | un A net exige une persistance prouvée |
Vérification reboot-proof (harden apply --reboot --scan) |
livré | re-scan après un vrai redémarrage |
Durcissement et exports
| Capacité | Statut | Notes |
|---|---|---|
| Durcir en code (plan Chef natif, opt-in par règle, dry-run) | livré | pas de script shell aveugle |
Annuler un durcissement (harden rollback) |
livré | restaure fichiers/paquets/services depuis un point de restauration pré-apply ; 96 % des contrôles, manques nommés (rollback) |
| Exports SARIF / JUnit / JSON / CSV / HTML | livré | voir Preuves & exports |
Verrou CI (--fail-under, codes de sortie) |
livré | voir Lancer Pavois en CI |
| Vérification comportementale (tenter l’action interdite) | livré | pavois verify |
Vérification de l’environnement (pavois doctor) |
livré | vérifie le moteur CINC, sudo, SSH, l’OS, le corpus de règles |
| Catalogue OSCAL + profils par OS | livré | voir Téléchargements |
| Rapport de campagne avant/après (matrice de transition) | livré | pavois diff --html |
| Bundle de preuve (manifeste + checksums, prêt à signer) | livré | pavois bundle |
| Posture par classe de remédiation + note remédiable | livré | voir Scoring |
| Résumé exécutif dans le rapport HTML | livré | top écarts + posture, côté client |
| Artefact reboot-proof (boot_id avant/après) | livré | harden apply --reboot |
| OSCAL assessment-results (un scan en OSCAL) | roadmap | le standard est livré ; le paquet scan-en-OSCAL pas encore |
Distribution et couverture
| Capacité | Statut | Notes |
|---|---|---|
Build depuis les sources (mise + go build) |
livré | voir Démarrer |
| Binaire de release signé et .deb/.rpm | livré | releases GitHub : binaires statiques (linux/darwin, amd64/arm64), paquets, checksums, SBOM CycloneDX, provenance SLSA et une signature Cosign |
| Image de conteneur | roadmap | aucune image publiée à ce jour |
| Audit du ruleset firewall (zones nft / ufw / firewalld) | partiel | présence et default-deny seulement |
| Logging : forwarding distant, intégrité | partiel | journald basique seulement |
| Audit de politique MAC (SELinux / AppArmor custom, AVC, unconfined) | partiel | statut enforcing seulement |
Le détail de couverture, avec le nombre de contrôles par domaine, est sur Ce que Pavois couvre.
Où le statut est suivi
Cette table fait foi pour le statut des capacités ; le travail sous-jacent est suivi dans les issues GitHub et le CHANGELOG du dépôt, et les versions livrées apparaissent dans les GitHub Releases. La page porte un dateModified pour voir quand elle a été revue.
FAQ
D'où vient le binaire de release signé ? Des releases GitHub du dépôt. Chaque artefact porte un SHA-256 dans checksums.txt, une provenance de build SLSA et une signature Cosign sans clé, toutes trois vérifiables sans aucun accès au dépôt. C'est suivi sur le dépôt, pas promis ici.
Le support OSCAL est-il complet ? Le catalogue et les profils par OS OSCAL sont livrés et téléchargeables ; seul le paquet assessment-results par scan est en roadmap.
Pourquoi marquer des choses partielles plutôt que les cacher ? Une référence gagne la confiance en nommant ses propres limites. partiel et roadmap sont énoncés pour qu'une note verte ne soit jamais prise pour une couverture totale.
À retenir
- Toutes les promesses phares ici sont livrées ; les manques restants sont une image de conteneur et la profondeur sur quelques domaines.
partieletroadmapsont nommés exprès : une référence gagne la confiance en marquant ses propres limites.