Corriger un faux positif sans créer de contournement : le cas snapd

À retenir+

Une liste blanche sur un nom ou un chemin peut être imitée par un attaquant.
On accepte un fichier seulement s'il est vérifiable de bout en bout.
Les limites du correctif sont écrites noir sur blanc.

Le problème

La règle D3 d'Hermian surveille les unités systemd, un endroit classique pour qu'un attaquant survive aux redémarrages. snapd écrit ses propres unités .mount dans /etc/systemd/system à chaque mise à jour d'un snap. Le ticket #113 signalait ces alertes sur une machine Ubuntu ordinaire.

Pour voir ces unités sur votre propre serveur :

ls /etc/systemd/system/snap-*.mount
systemctl list-units --type=mount | grep snap

Le piège de la liste blanche

Ignorer tout ce qui ressemble à une unité snapd réglait le bruit en une ligne. Mais n'importe qui capable d'écrire une unité aurait pu l'appeler snap-quelquechose.mount et passer inaperçu. Un correctif de faux positif ne doit jamais devenir une méthode de dissimulation.

Le correctif

Dans la demande de fusion #115, une unité n'est acceptée que si les quatre conditions tiennent :

elle suit exactement le modèle que snapd génère, avec seulement les clés attendues ;
elle monte /snap/NOM/RÉVISION avec les options nodev et ro ;
le fichier .snap appartient à root et personne d'autre ne peut le modifier ;
son empreinte SHA3-384 correspond à une assertion du store pour ce snap.

Une unité qui passe les quatre contrôles est journalisée en INFO. Une seule condition manquante, et l'alerte part comme avant.

Les limites, écrites

L'empreinte est recalculée à chaque fois, sans cache : un .snap réécrit en place peut garder le même inode, la même taille et la même date. La signature des assertions n'est pas vérifiée. Un attaquant déjà root pourrait en forger une, mais il n'obtiendrait qu'un montage en lecture seule, sans périphériques.

État

Testé sur Ubuntu 22.04 avec snapd 2.78 : 24 unités reconnues. Le correctif est en revue.