Vérifier les permissions du répertoire /etc/sysctl.d
Garantit que le répertoire de drop-ins /etc/sysctl.d n'est modifiable que par root, afin que les paramètres de durcissement du noyau ne puissent être discrètement écrasés au démarrage.
Vérifié sur l’état résolu en cours d’exécution (ex. sshd -T, sysctl, systemctl show), attrape les drop-ins et Include qu’une lecture de fichier raterait. Réserve : runtime ≠ persistance ; une valeur correcte maintenant peut ne pas survivre à un redémarrage.
Pavois vérifie la configuration effective, l’état résolu et réellement appliqué, pas un fichier. Les scanners basés fichier (OVAL/SCAP, Lynis) ratent les Include, drop-ins et défauts runtime ; ce check voit ce qui est réellement en vigueur.
Un mapping est une référence croisée vers l’endroit où chaque norme situe cette exigence, ancrée et recoupée, pas une affirmation d’équivalence. Un check réussi est une preuve vers ces références, comment le lire.
Pourquoi cette règle
Le répertoire /etc/sysctl.d héberge des drop-ins de réglage du noyau appliqués au démarrage (et par sysctl --system). Ces réglages gouvernent des comportements sensibles comme le forwarding IP, l'ASLR, kptr_restrict et le durcissement réseau. Si le répertoire est modifiable par le groupe ou les autres, un utilisateur non privilégié pourrait y déposer un fichier qui désactive une protection du noyau au prochain démarrage. Restreindre l'écriture à root seul (pas d'écriture groupe/autres, pas de setuid/setgid/sticky) garantit le contrôle exclusif de la configuration du noyau.
Ce que vérifie Pavois
Pavois lit le mode effectif du répertoire /etc/sysctl.d et vérifie l'absence de bit d'écriture pour le groupe ou les autres et l'absence de bits setuid/setgid/sticky. Protégé par only_if { file('/etc/sysctl.d').exist? }. Comme sysctl est un mécanisme de drop-in, la sécurité du répertoire lui-même compte autant que celle des fichiers : un répertoire modifiable permet d'ajouter un nouveau .conf que le noyau appliquera, vérifier l'inode réel détecte précisément cette exposition.
only_if { file('/etc/sysctl.d').exist? }
describe file('/etc/sysctl.d') do
it { should_not be_setuid }
it { should_not be_writable.by('group') }
it { should_not be_setgid }
it { should_not be_writable.by('other') }
it { should_not be_sticky }
endComment vérifier qu’elle est appliquée
Exécutez stat -c '%a %U %G' /etc/sysctl.d. La sortie attendue est 755 root root ou plus strict (par ex. 750) : aucun bit d'écriture pour le groupe ou les autres, et le répertoire appartenant à root. Listez les valeurs actives avec sysctl --system pour confirmer que seuls les drop-ins prévus sont appliqués.
Inspecter et investiguer
stat /etc/sysctl.d affiche le mode du répertoire. Pour confirmer l'état effectif du noyau, interrogez la valeur réelle, par ex. sysctl net.ipv4.ip_forward. Les ajouts/modifications dans le répertoire apparaissent dans /var/log/audit/audit.log si une surveillance d'audit est configurée.
Remédiation
Aucun plan de durcissement automatisé n'est défini pour cette règle, appliquez-la donc manuellement : chown root:root /etc/sysctl.d puis chmod 0755 /etc/sysctl.d (le répertoire doit rester lisible/traversable pour que sysctl --system charge les drop-ins).
Pavois applique ceci avec son propre moteur harden, le plan ci-dessous, pas un script shell :
| mode | 0755 |
|---|---|
| path | /etc/sysctl.d |
| resource | file |
pavois harden plan localoù la cible est local, un alias SSH user@hôte, ou un conteneur , Docs
Impact & précautions
Un /etc/sysctl.d modifiable par le groupe ou tous permet à un utilisateur non privilégié d'y déposer un drop-in désactivant des protections du noyau (par ex. réactiver ip_forward ou affaiblir l'ASLR) au prochain redémarrage, un vecteur furtif de persistance et d'affaiblissement des privilèges. Précautions : ne supprimez pas la lecture/exécution sur le répertoire ; le noyau et sysctl --system doivent le traverser, utilisez donc 0755 et non 0700 pour ne pas casser l'application au boot de vos paramètres de durcissement.
Mapping des normes
| Norme | Référence | Type | Version | Confiance |
|---|---|---|---|---|
| ANSSI BP-028 | R50 | direct | 2.0 | haute |
Chaque référence est une référence croisée ancrée dans le benchmark amont et recoupée avec le SCAP Security Guide et ansible-lockdown, pas une affirmation d’équivalence. Direct = une exigence prescriptive au niveau de la ligne ; support = une famille de contrôle abstraite (NIST) vers laquelle le check apporte une preuve. Comment lire un mapping.