← Toutes les règles
SOCLE-CLD-MNT-015// Mountsmoyenneruntime effectif

Ajouter l'option nosuid à /tmp

Monte /tmp avec l'option nosuid afin que le noyau ignore les bits set-UID/set-GID des binaires de ce répertoire.

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é →
Debian 12CIS 1.1.0Debian 13CIS 1.0.0FedoraRHEL 10 / Rocky 10 / AlmaLinux 10RHEL 8 / Rocky 8 / AlmaLinux 8CIS 4.0.0RHEL 9 / Rocky 9 / AlmaLinux 9CIS 2.0.0Ubuntu 22.04CIS 3.0.0Ubuntu 24.04CIS 1.0.0Ubuntu 26.04
Un seul check, mappé sur 3 normes

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

Les exécutables SUID et SGID s'exécutent avec les privilèges de leur propriétaire (souvent root) plutôt que de l'utilisateur appelant ; leur présence doit donc être strictement contrôlée. L'option nosuid force le noyau à ignorer les bits set-user-ID et set-group-ID de tout binaire sous /tmp. Comme /tmp est accessible en écriture à tous, un attaquant pourrait sinon y déposer un binaire SUID-root et l'utiliser pour une élévation de privilèges ; nosuid neutralise cette voie.

Ce que vérifie Pavois

Pavois inspecte le montage effectif via mount('/tmp') et vérifie que ses options résolues incluent nosuid. Il lit la table de montage active du noyau, les options réellement appliquées, au lieu de /etc/fstab ; il détecte donc une partition remontée sans le drapeau, un écrasement par une unité systemd, ou une entrée fstab jamais appliquée, ce qu'un scanner basé sur les fichiers validerait à tort.

describe mount('/tmp') do
  its('options') { should include 'nosuid' }
end
describe command("{ findmnt --fstab -no OPTIONS /tmp 2>/dev/null; grep -hsE '[[:space:]]/tmp[[:space:]]' /etc/fstab 2>/dev/null; systemctl show -p Options -- $(systemd-escape -p --suffix=mount /tmp 2>/dev/null) 2>/dev/null; } | grep -ow 'nosuid'") do
  its('stdout') { should match(/\S/) }
end

Comment vérifier qu’elle est appliquée

Exécutez findmnt /tmp (ou findmnt -no OPTIONS /tmp) et confirmez que nosuid figure dans la liste des options. La sortie attendue contient nosuid, par exemple /tmp ... rw,nosuid,nodev,noexec,relatime.

Inspecter et investiguer

L'état du montage s'interroge en direct avec findmnt /tmp ou cat /proc/mounts, pas depuis un log. Les événements de démarrage et de remontage apparaissent via journalctl -b | grep -i tmp ou journalctl -u tmp.mount.

Remédiation

Aucun plan de durcissement automatisé n'est fourni pour cette règle ; elle doit donc être appliquée manuellement : ajoutez nosuid aux options de l'entrée /tmp dans /etc/fstab (ou à l'unité de montage systemd concernée), puis mount -o remount /tmp, ou redémarrez, et relancez le scan pour confirmer.

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

devicetmpfs
fstypetmpfs
mount_point/tmp
optionnosuid
resourcemount
pavois harden plan local

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

Impact & précautions

L'impact fonctionnel est faible : les charges légitimes ne placent pas de binaires SUID/SGID dans /tmp. Précautions : confirmez que /tmp est un montage dédié avant d'appliquer ; appliquez avec mount -o remount /tmp. Le risque est négligeable face à noexec, car seuls les bits de privilège sont neutralisés, les programmes normaux (non SUID) ne sont pas affectés.

Mapping des normes

NormeRéférenceTypeVersionConfiance
ANSSI BP-028R28direct2.0haute
CIS1.1.2.1.3directper OS, see the benchmark tablehaute
NISTAC-6, AC-6(1), CM-6(a), CM-7(a), CM-7(b), MP-7support800-53 Rev 5 · 800-171 Rev 2 (pinned)moyenne

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.

Sources & références