Exploiter Pavois : privilèges, air-gap, durée, dérogations

Quatre questions décident si Pavois convient à votre environnement, et aucune n'a de réponse à la fois confortable et vraie. Voici les vraies.

D'abord, à 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 avec harden apply.

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 (53 des 281 contrôles en échec sur une debian 12 neuve : les classes install-time et kernel-build). C'est la réponse honnête, et elle vaut pour tous les outils : une table de partitions n'est pas un réglage.

Privilèges : root, et pourquoi un sudoers restreint ne suffit pas

Pavois audite la configuration effective, et les commandes qui la produisent sont privilégiées : sshd -T (root uniquement), auditctl -l, sysctl -a, la lecture de /etc/shadow. Il n'existe pas de sous-ensemble en lecture seule qui donne les mêmes réponses.

Deux transports, deux empreintes sudo très différentes :

--on-target est donc le mode à choisir pour un sudoers cadré : le compte peut être restreint au seul cinc-auditor. Mais soyons lucides sur ce que cela achète : cinc-auditor tourne alors en root et peut tout ce que root peut. C'est une surface d'attaque plus petite pour un identifiant volé, pas une frontière de privilèges.

Le mot de passe sudo n'atteint jamais argv : il est passé au moteur sur l'entrée standard (--config -), donc illisible depuis ps ou /proc/<pid>/cmdline. Utilisez --sudo-prompt (sans écho) ou la variable PAVOIS_SUDO_PASSWORD. Passer --ssh-pass en ligne de commande est possible et déconseillé, exactement pour la raison que vous imaginez.

Quel drapeau sudo, et ce qu'une image cloud vous donne

Trois façons d'obtenir root, et la bonne dépend du sudoers de la cible, pas d'une préférence :

Vérifiez avant de choisir, cela tient en une commande :

ssh user@host 'sudo -n true && echo NOPASSWD || echo "sudo veut un mot de passe"'

Si la réponse est NOPASSWD, utilisez --sudo. C'est presque toujours le cas dans le cloud : AWS, Outscale, Scaleway, Azure et les images officielles Debian, Ubuntu et RHEL provisionnent toutes leur compte par défaut en NOPASSWD:ALL.

Ne répondez pas par un mot de passe vide. --sudo-prompt sur un hôte NOPASSWD réclame quelque chose qui n'existe pas, et appuyer sur Entrée transmet à Pavois un mot de passe vide, ce qui n'est pas la même chose que « pas de mot de passe nécessaire ». Jusqu'à la v0.3, cette combinaison figeait harden apply sur photographing the prior state (restore point), sans erreur ni expiration. C'est corrigé, mais le drapeau reste le mauvais : utilisez --sudo.

Scanner sans root ne donne pas une réponse partielle, il donne une réponse fausse. Les sondes privilégiées ne renvoient rien du tout sans privilège (sshd n'est même pas dans un PATH ordinaire), et chaque contrôle qui les lit signale un écart que personne n'a mesuré. Sur un hôte que nous venions de durcir, retirer --sudo a transformé une note C sans aucun critique en note E avec 2 critiques fabriqués de toutes pièces. pavois scan refuse désormais de tourner sans privilège plutôt que de publier cela ; --allow-unprivileged lève le refus si vous comprenez ce que le rapport signifie alors.

Air-gap : ce qui exige réellement le réseau

Trois choses sortent, et chacune a une réponse hors-ligne :

Le corpus de règles est local (il est livré avec le binaire), le bundle OSCAL est généré localement, et un scan n'envoie rien nulle part. Un scan en environnement cloisonné est un problème résolu : mettez CINC dans l'image, et Pavois est hors-ligne par construction.

Combien de temps dure un scan

Mesuré le 14 juillet 2026, sur une VM debian 12 (2 vCPU, 3 Go, même réseau local), 620 contrôles, temps réel d'un pavois scan complet dans chaque mode :

Sept fois plus rapide, et l'écart se creuse avec la latence : sur un lien WAN, le mode SSH est dominé par les allers-retours, pas par les vérifications. --on-target copie le profil sur la cible et y exécute le moteur, ce qui explique qu'il l'exige sur place.

Une boucle de flotte est donc peu coûteuse : 200 hôtes × 13 secondes, parallélisés, cela fait des minutes, pas une soirée.

Dérogations : deux choses différentes, une seule est un waiver

Un waiver est un contrôle que Pavois choisit délibérément de ne pas imposer, parce que l'imposer casserait quelque chose que le projet classe plus haut. Il vit dans la base de règles (champ waiver: de rules.yml), se rend dans le waivers.yml du profil, et le scan rapporte le contrôle comme dérogé plutôt qu'en échec. La justification est ce que lit l'auditeur :

# profiles/linux/<os>/waivers.yml (généré : la source est rules.yml)
kmod-loading-disabled:
  justification: 'kernel.modules_disabled=1 bloque définitivement le chargement de modules, ce qui
    prive le pare-feu nftables de nf_conntrack (nécessaire à `ct state`) et peut couper SSH. L'imposer
    casserait un contrôle que nous classons plus haut (un pare-feu qui fonctionne). Risque accepté :
    les modules restent chargeables.'
  run: false

C'est le risque accepté de Pavois, livré avec l'outil, identique pour tous. Ce n'est pas votre dérogation.

Votre dérogation est une décision métier, et elle appartient à la preuve, pas à la base de règles : ce contrôle, sur cet hôte, n'est pas appliqué, pour cette raison, jusqu'à cette date, approuvé par cette personne. pavois bundle --exceptions <fichier> scelle ce fichier dans le paquet de preuve, aux côtés des scans avant/après, du plan et du manifeste d'empreintes. Pavois n'impose pas de schéma ; un auditeur attend au minimum, par entrée : l'identifiant du contrôle, l'hôte, la raison, la mesure compensatoire, la date d'expiration et l'approbateur. Une dérogation datée et compensée est une décision ; une dérogation sans date est un trou avec de la paperasse.

FAQ

Puis-je scanner sans root ? Non, pas utilement. sshd -T refuse, auditctl -l refuse, /etc/shadow refuse. Un scan non privilégié rapporterait une silhouette du système, pas sa configuration effective, qui est la seule chose que Pavois existe pour lire.

Puis-je restreindre sudo à un seul binaire ? Avec --on-target, oui : cinc-auditor. Comprenez qu'il tourne alors en root ; vous avez réduit ce qu'un identifiant volé peut invoquer, pas ce que le scan peut faire.

Pavois envoie-t-il des données vers l'extérieur ? Non. La seule chose qu'il récupère est l'installeur CINC depuis omnitruck, et uniquement si vous passez --bootstrap-cinc, aussi bien pour un scan que pour un apply. Sans ce drapeau, il s'arrête et affiche la commande qu'il aurait lancée. Rien d'autre ne quitte jamais la machine.

Pourquoi --on-target n'est-il pas le défaut ? Parce qu'il exige le moteur installé sur la cible. Le mode SSH fonctionne contre un hôte sur lequel rien n'est installé, ce qui est le bon défaut pour un premier contact.

Pavois peut-il durcir un serveur de production en service ? En partie, et il vous dira laquelle. Tout sauf install-time et kernel-build s'applique à chaud, et la note remédiable est exactement le score de ce qu'il peut atteindre sans reconstruction. Le reste est un problème d'image, et il doit se régler là où les images se fabriquent.

À retenir

• Pavois sert à construire une image conforme, et à détecter la dérive par rapport à elle. Ce n'est pas un rattrapage pour un hôte legacy, et les classes install-time / kernel-build sont l'endroit où cette vérité est écrite.
• Root est requis, parce que la configuration effective est privilégiée. --on-target permet de cadrer sudo sur un seul binaire, et va 7 fois plus vite (13 s contre 90 s sur 620 contrôles).
• L'air-gap est un problème résolu : pré-installer CINC dans l'image, pointer les remédiations de paquets sur un miroir interne, et Pavois ne touche plus le réseau.
• Un waiver est le risque accepté de Pavois. Votre dérogation est une décision métier datée, approuvée et compensée, et sa place est dans le paquet de preuve.

Prochaines étapes

• Démarrer · Lancer Pavois en CI · Preuves & exports