Configuration effective : la vérité qu'aucun fichier ne contient

Le drop-in est le cas facile

L'argument habituel : un scanner de fichiers lit /etc/ssh/sshd_config, rate le drop-in dans sshd_config.d/, et rapporte une valeur surchargée. Vrai, mais ça sous-vend le propos, car un scanner de fichiers compétent peut lui aussi globber sshd_config.d/*. Si c'était toute l'histoire, mieux parser les fichiers suffirait à combler l'écart.

Ce n'est pas toute l'histoire. La raison d'interroger le système en exécution, c'est qu'une large part de la configuration effective n'est dans aucun fichier, et qu'aucun parsing de fichiers ne l'atteint. Pavois appelle sshd -T, sysctl, systemctl show, auditctl -l précisément parce que ces commandes renvoient l'état résolu, défauts et runtime compris.

Trois choses qu'aucun fichier ne vous dit

1. Les défauts que personne n'a écrits

Une directive que vous n'avez jamais posée a quand même une valeur effective : le défaut compilé du démon. sshd -T imprime les ~90 directives effectives, y compris celles absentes de tout fichier de /etc/ssh. CIS et STIG exigent couramment une valeur précise pour une directive que la plupart des hôtes laissent par défaut (MaxAuthTries, ClientAliveInterval, LoginGraceTime). Un scanner qui lit sshd_config et tous les drop-ins ne trouve rien à vérifier : la valeur vit dans le binaire. Seul l'appel au démon dit si le défaut sur lequel vous comptez est le bon.

2. Précédence résolue et défauts noyau

Une valeur sysctl en cours d'exécution est calculée depuis une pile : le défaut intégré du noyau, puis /usr/lib/sysctl.d/, /run/sysctl.d/, /etc/sysctl.d/, /etc/sysctl.conf, dernier écrivain gagnant, à travers des répertoires que personne ne regarde. Lire /etc/sysctl.conf vous donne une entrée sur six, et pas même celle faisant autorité. sysctl net.ipv4.conf.all.rp_filter renvoie l'unique valeur que le noyau applique maintenant ; la reconstruire depuis les fichiers, c'est réimplémenter les règles de précédence du noyau en espérant ne pas s'être trompé d'ordre.

3. L'état sans fichier

Une partie de la configuration n'a aucun fichier source à lire. Les générateurs systemd synthétisent des unités au boot (systemd-fstab-generator transforme les lignes de /etc/fstab en unités de montage vivantes, systemd-getty-generator crée des unités getty), et systemctl show résout presets fournisseur, drop-ins d'une dizaine de répertoires et ces unités générées en une seule réponse effective. De même auditctl -l liste les règles réellement appliquées par le noyau, qui peuvent différer de audit/rules.d/ quand augenrules les a fusionnées autrement ou qu'une règle a échoué à se charger ; et /proc/cmdline est ce avec quoi le noyau a réellement démarré, pas ce que propose GRUB. Il n'existe tout simplement aucun fichier qui détient la réponse.

Un exemple SSH concret

Un hôte réel, trois fichiers :

/etc/ssh/
├── sshd_config              # Include /etc/ssh/sshd_config.d/*.conf
│                            # PermitRootLogin yes
│                            # #MaxAuthTries 6     <- commente : laisse au defaut
└── sshd_config.d/
    ├── 50-cloud-init.conf   # PasswordAuthentication yes
    └── 99-hardening.conf    # PermitRootLogin no

Lisez seulement sshd_config et vous concluez que le login root est autorisé, faux, le drop-in l'a surchargé. Lisez tous les fichiers et vous obtenez PermitRootLogin no, mais vous ne trouvez toujours rien sur MaxAuthTries : il est commenté partout. Maintenant interrogez le démon, la commande exacte qu'exécute Pavois :

sshd -T | grep -E 'permitrootlogin|passwordauthentication|maxauthtries'
# permitrootlogin no          <- résolu après le drop-in (le fichier disait yes)
# passwordauthentication yes  <- du drop-in cloud-init
# maxauthtries 6              <- defaut compile, dans AUCUN fichier

Trois faits en ressortent, que les fichiers ne peuvent pas donner ensemble : le permitrootlogin no résolu (donc ssh-disable-root-login, CIS 5.1.x / ANSSI BP-028 R33, passe), un passwordauthentication yes facile à rater à l'oeil, et maxauthtries 6, le défaut compilé dans aucun fichier, où CIS exige 4, donc ssh-set-max-auth-tries échoue. Pavois remonte cette troisième ligne comme un vrai finding, avec la valeur effective 6 pour preuve.

Effective (runtime) contre persistant (config)

Les deux questions sont différentes, et Pavois dit explicitement laquelle il répond par contrôle :

Limites : le runtime n'est pas la persistance

Lire l'état résolu prouve la valeur actuelle ; cela ne prouve pas qu'elle survit à un redémarrage. Un sysctl -w posé à l'exécution et jamais écrit dans /etc/sysctl.d/ est conforme maintenant et régresse au prochain boot. C'est pourquoi Pavois sépare les deux axes dans son verdict qualifié : un contrôle peut prouver en cours d'exécution sans prouver persistant, et la note le reflète. Chaque contrôle déclare la preuve qu'il collecte (runtime, config persistante, inventaire, système de fichiers), pour que le rapport ne confonde jamais vrai maintenant et vrai après redémarrage. La configuration effective est nécessaire et puissante ; ce n'est pas la persistance, et Pavois le dit par contrôle plutôt que de prétendre le contraire.

Pourquoi c'est tout le design

Soyons précis sur cette ligne, car une version négligente de l'argument est fausse. SCAP n'est pas purement basé sur les fichiers : OVAL a un sysctl_test qui lit /proc/sys, et un systemdunitproperty_test qui interroge systemd, donc « il ne lit que des fichiers » est faux, et un mainteneur d'OpenSCAP le dira. La vraie ligne, défendable, est plus étroite et reste décisive : aucune sonde SCAP n'interroge le démon lui-même. Aucune ne lance sshd -T pour obtenir la valeur qu'OpenSSH a résolue après chaque Include, bloc Match et défaut ; aucune ne reproduit la précédence premier-mot-clé-gagne à travers un arbre d'inclusions arbitraire ; aucune ne lit la politique effective d'un service qui la garde en mémoire, pas sur disque. Pavois interroge le programme qui possède le réglage. C'est ce que l'analyse de fichiers, si minutieuse soit-elle, ne peut pas atteindre. Pavois audite l'état résolu parce que c'est le seul état qu'un attaquant, et votre noyau, obéit réellement.

FAQ

Pourquoi ne pas juste parser soigneusement les fichiers de config ? Parce que les défauts compilés, la précédence sysctl à six niveaux et les unités synthétisées par générateur n'ont aucun fichier à parser. Le parsing de fichiers atteint les drop-ins ; il n'atteint jamais l'état qui ne vit que dans le noyau et les démons en exécution.

Un PASS effectif signifie-t-il qu'il survit à un redémarrage ? Non. Il prouve que la valeur est en vigueur maintenant. La persistance est un axe distinct que suit le verdict qualifié ; un pass runtime-seulement est plafonné en conséquence.

Quelles commandes Pavois exécute-t-il ? Celles de l'état résolu : sshd -T, sysctl, systemctl show, auditctl -l, et des lectures de /proc/cmdline et /proc/self/mountinfo, jamais le fichier de config nu quand un démon peut rapporter son état effectif.