← Toutes les règles
SOCLE-CLD-KRN-018// Kernel command linemoyenneruntime effectif

Désactiver les vsyscalls

Impose le paramètre noyau vsyscall=none pour supprimer la page vsyscall héritée à adresse fixe de la mémoire des processus.

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.

Un PASS prouve✓ actif maintenant✓ sur disque✓ survit au rebootle verdict qualifié →
FedoraRHEL 10 / Rocky 10 / AlmaLinux 10RHEL 8 / Rocky 8 / AlmaLinux 8CIS 4.0.0RHEL 9 / Rocky 9 / AlmaLinux 9CIS 2.0.0

Pourquoi cette règle

L'ancien mécanisme vsyscall mappe une petite région fixe et exécutable de code noyau à une adresse prévisible dans chaque processus. Comme son emplacement est statique, il fournit une cible fiable (gadgets ROP) à un attaquant qui contrôle déjà le pointeur d'instruction de retour, affaiblissant l'ASLR. Définir vsyscall=none supprime ce mappage fixe ; la glibc moderne utilise le vDSO à la place et n'est pas affectée.

Ce que vérifie Pavois

Pavois lit la ligne de commande de démarrage effective depuis /proc/cmdline, les arguments avec lesquels le noyau a réellement démarré. C'est plus fiable qu'un grep dans /etc/default/grub ou grub.cfg, qui peuvent être modifiés sans régénération, surchargés par des drop-ins sous /etc/default/grub.d/, ou désynchronisés de l'entrée active du chargeur d'amorçage. Seul /proc/cmdline prouve que vsyscall=none est appliqué sur ce boot.

describe command('cat /proc/cmdline') do
  its('stdout') { should match(/(^| )vsyscall=none( |$)/) }
end
describe command("grep -hwsF 'vsyscall=none' /etc/default/grub /etc/kernel/cmdline /boot/grub/grub.cfg /boot/grub2/grub.cfg /boot/efi/EFI/*/grub.cfg 2>/dev/null") do
  its('stdout') { should match(/\S/) }
end

Comment vérifier qu’elle est appliquée

Exécutez cat /proc/cmdline et vérifiez la présence de vsyscall=none. Sur un système durci, cat /proc/self/maps | grep vsyscall ne devrait plus afficher de mappage exécutable [vsyscall] (ou l'afficher comme retiré).

Inspecter et investiguer

Examinez le tampon noyau avec dmesg | grep -i vsyscall pour voir comment le noyau signale le mode vsyscall au démarrage. Vous pouvez aussi confirmer l'absence de la page héritée par processus via cat /proc/<pid>/maps | grep vsyscall.

Remédiation

Aucun plan de durcissement automatisé n'est défini pour cette règle (remediation est vide), elle doit donc être appliquée manuellement : ajoutez vsyscall=none à la ligne de commande noyau (par ex. via GRUB_CMDLINE_LINUX dans /etc/default/grub puis grub2-mkconfig, ou grubby --update-kernel=ALL --args=vsyscall=none sous RHEL) et redémarrez.

Pavois applique ceci avec son propre moteur harden, le plan ci-dessous, pas un script shell :

paramvsyscall=none
reboot_requiredtrue
resourcekernel_cmdline
pavois harden plan local

où la cible est local, un alias SSH user@hôte, ou un conteneur , Docs

Impact & précautions

Laisser la page vsyscall mappée offre aux attaquants une cible stable et exécutable qui sape l'ASLR. La désactiver nécessite un redémarrage et peut casser de très anciens binaires liés statiquement ou une glibc héritée (antérieure à 2.14) appelant encore directement les vsyscalls, l'espace utilisateur moderne basé sur le vDSO n'est pas affecté. Précautions : testez les applications héritées, préférez d'abord vsyscall=emulate si vous devez supporter d'anciens binaires, planifiez le redémarrage et conservez un accès console en cas de problème de démarrage.

Sources & références