Comment fonctionne Pavois

À quoi sert Pavois

Pavois construit une image conforme. Il ne rattrape pas un système legacy mal configuré depuis dix ans.

Ce n'est pas une limite dont il faut s'excuser, c'est la forme du problème. Un système de fichiers /var/log séparé se décide au partitionnement du disque ; un noyau sans les options KSPP ne peut pas les acquérir en marche. Ces contrôles portent les classes install-time et kernel-build précisément parce qu'aucun apply ne peut les fermer sur une machine de production en service : on ne repartitionne pas un serveur qui répond au trafic.

Le parcours qui fonctionne est donc :

1. Construire, une image cloud neuve + la recette de partitionnement + la recette de noyau + un harden apply convergé. C'est votre image de référence, et sa note est celle dont votre flotte part.
2. Livrer, la figer (Packer, une chaîne d'images, un template).
3. Surveiller, scanner la flotte en service pour détecter la dérive par rapport à l'image livrée, et la ramener.

Lancez-le sur un hôte legacy et il vous dira quand même la vérité, en détail, avec une note. Il vous dira simplement aussi qu'environ un écart sur cinq exige une reconstruction, pas une commande, et la note remédiable est exactement le score de ce qu'il peut atteindre sans elle. Exploiter Pavois couvre les privilèges, l'air-gap, la durée et les dérogations.

Vue d'ensemble

Pavois est un scanner de conformité bâti sur CINC Auditor (le build open-source de Chef InSpec). Il vérifie un système Linux contre des normes (CIS, ANSSI-BP-028, NIST, PCI-DSS) et produit un rapport noté A:E, structuré par chapitre, comme OpenSCAP, mais il audite la configuration effective (sshd -T, sysctl, systemctl show, auditctl -l…), captant les Include et drop-ins que les scanners par fichier ratent.

En une ligne : pavois scan local --sudo

L'installation est sur la page Installation (binaire signé ou depuis les sources) et Démarrer (premier scan en 5 minutes).

Cibles

Chaque commande prend une cible, ce qu'on scanne ou durcit :

Le mode natif utilise votre ~/.ssh/config et votre routage, aucun agent. Les services lus en root (sshd, auditd…) nécessitent --sudo.

scan, auditer & noter

pavois scan <cible> [flags], auditer la config effective et noter A:E. Pavois auto-détecte l'OS de la cible et choisit le profil par-OS correspondant : on passe rarement --profile (seulement pour pointer un profil perso).

pavois scan admin@server1 --key ~/.ssh/id --standard cis --level 1 --fail-under 80
pavois scan local --sudo --format html

Identifiants, sans fuite de mot de passe

Les mots de passe n'atteignent cinc-auditor que par stdin (--config -), jamais la ligne de commande, donc illisibles dans ps, /proc/<pid>/cmdline ou l'historique du shell.

pavois scan admin@server1 --sudo-prompt --standard cis      # demande, sans écho
PAVOIS_SUDO_PASSWORD=… pavois scan admin@server1 --sudo    # CI / automatisation

Les variables d'env sont désactivées dès leur lecture et retirées de chaque process enfant : rien n'en hérite. Évitez le flag inline --ssh-pass <valeur>, il fuit via ps et l'historique ; le prompt et l'env sont les voies sûres.

Defaults use_pty (un défaut Debian) fait échouer le sudo en SSH natif avec « Sudo requires a TTY », indépendamment du mot de passe. Utilisez --on-target, cinc tourne sur la cible avec un vrai pty.

harden, planifier & appliquer

Le durcissement est un flux en quatre temps, conscient de l'état, jamais un script aveugle.

1. Planifier, scanner et écrire hardening-plan-<os>.yml :

pavois harden plan local --sudo

Chaque règle apparaît avec son status (compliant ou un écart) et un interrupteur apply: à false par défaut, rien ne change tant que vous n'optez pas :

rules:
  ssh-disable-root-login:
    status: non-compliant   # un écart
    apply: false            # <- passer à true pour corriger cette règle

2. Éditer, basculer apply: false en true sur les règles à corriger (et true en false pour en ignorer une). baseline_packages fonctionnent pareil (true retire le paquet).

3. Appliquer, passer le plan édité :

pavois harden apply hardening-plan-debian12.yml --dry-run   # prévisualiser la recette Chef
pavois harden apply hardening-plan-debian12.yml --scan       # appliquer, puis re-scanner

apply prend un fichier plan, pas une cible. Il compile les éléments activés en un run Chef natif (pas de bash) et converge.

4. Valider, prouver que l'apply a bien corrigé ce que le plan avait trouvé :

pavois diff hardening-plan-debian12.yml reports/<scan-post-apply>.json

diff accepte un plan ou un scan de chaque côté. Plan vs scan post-apply liste chaque écart fermé par le durcissement (✔ fixed) et toute régression, la preuve qu'un durcissement a réussi. (Scan vs scan marche aussi, pour avant/après.)

verify & diff

• pavois verify <cible>, validation comportementale : il tente l'action interdite et confirme que la protection tient vraiment (pas seulement qu'un réglage est présent).
• pavois diff <avant.json> <après.json>, compare deux rapports : règles corrigées / régressées / (dés)activées et le delta de note. Idéal avant/après un harden apply, ou comme gate de non-régression en CI.

Formats de sortie & CI

--format pilote la sortie : table (terminal), html (le rapport chapitré), json, sarif (GitHub code scanning), junit (rapport de test CI), csv.

Le code de sortie est le verrou CI : 0 conforme · 1 sous le seuil --fail-under · 2 erreur technique (les codes 100/101 de CINC n'atteignent jamais votre shell). Référence complète. À combiner avec --fail-under :

# GitHub Actions
- run: pavois scan local --sudo --standard cis --format sarif --out report
- uses: github/codeql-action/upload-sarif@v3
  with: { sarif_file: report }

pavois serve --port 8098 sert les rapports HTML en HTTP.

La note A:E derrière --fail-under suit une formule publiée et figée, poids, plafonds par sévérité et règle d’échec critique sont détaillés dans Comment la note A:E est calculée.

Profils & normes

Un profil est l'ensemble de contrôles exécutés. Pavois auto-détecte l'OS et utilise le profil par-OS correspondant sous profiles/linux/<os> (p.ex. profiles/linux/debian12) ; on peut aussi passer --profile avec un chemin ou une URL vers un profil perso.

pavois profiles les liste ; Pavois standards (alias normes) explique les normes et leurs niveaux. Une norme est une vue, un contrôle porte N mappings (CIS / ANSSI / NIST / PCI), jamais une règle dupliquée. Chaque OS cible sa version de benchmark. Voir les pages normes.

API JSON

Pavois expose sa référence en JSON, le contrat consommable :

pavois norms --pretty                 # le catalogue de normes (versions, autorités, couverture)
pavois rules --os debian12 --standard cis   # la base de règles, filtrée

pavois rules accepte --os, --standard, --domain, --pretty ; pavois norms n'accepte que --pretty. La référence complète est générée depuis le binaire.