Ramdisks contenant des données sensibles

Contexte

Souvent, sur une machine, et en particulier sur un serveur, on veut que des données :

• soient stockées pour une durée limitée, pour des raisons pratiques du point de vue sysadmin ;
• ne soient pas écrites sur le disque dur, pour ne pas être en mesure de les donner à des gens qui ne doivent pas y avoir accès.

Par exemple, ça peut être le cas pour /tmp, pour les ErrorLog Apache contenant des IPs, ou pour mail.{err,log,...}.

Une solution classique consiste en l'utilisation d'un ramdisk. Il s'agit d'un système de fichiers volatile, c'est-à-dire qu'ils ne correspond à aucune partition, et qu'il est perdu lorsque le courant de la machine est coupé, que ce soit proprement (shutdown -h) ou salement (oups, j'ai débranché le câble d'alimentation).

Solutions disponibles

Sous GNU/Linux, il y en a deux sortes plus ou moins adaptées à l'usage dont nous causons présentement.

tmpfs

Il supporte des options de montage bien pratiques : uid, gid, mode, limites de taille en octets et en nombre d'inodes.

PAR CONTRE, SON CONTENU PEUT TRÈS BIEN SE RETROUVER ÉCRIT DANS LE SWAP, DONC IL EST PRIMORDIAL, SI CE RAMDISK EST AMENÉ À CONTENIR DES INFOS SENSIBLES (IPS, ETC.), D'AVOIR UN SWAP CRYPTÉ.

(Ce qui n'est pas parfait, il est des données qu'on voudrait bien ne jamais voir écrites sur un disque dur, qu'il soit crypté ou non.)

Exemple de ligne dans /etc/fstab pour un tel ramdisk :

tmpfs /tmp tmpfs noexec,nosuid,nodev,size=100M,uid=root,gid=root,mode=1777 1 2

Enfin, pour les gros besoins de sécurité, il est toujours possible avec dm-crypt ou loop-aes d'utiliser un tmpfs crypté

ramfs

Il apporte, lui, la garantie que son contenu n'aille jamais dans le swap.

Par contre, il ne supporte pas les options de montage uid, gid, mode, et aucune limite de taille. Pour les permissions (uid,gid,mode), un script d'init. lancé après le montage peut faire l'affaire, mais c'est pénible. Pour la limite de taille, c'est vraiment embêtant, car c'est possible je pense de freezer complètement une machine en lui remplissant à mort le /tmp, ce que n'importe qui a le droit de faire, et vu que ces infos ne peuvent pas aller dans le swap, ben c'est la merde.

Conclusion

Ramfs, c'est mignon, ça ne se swappe pas, mais ça rend assez aisé de faire un DoS^? sur la machine, pour un·e attaquant·e qui sait que vous utilisez ce système de fichiers pour /tmp, par exemple.

Donc, ben, c'est un peu un choix entre la peste et le choléra. À vous de voir. La tendance semble être d'utiliser du tmpfs, en faisant bien gaffe d'avoir du swap crypté.

Post-scriptum

Et de toute façon, avoir un swap crypté, sur une machine qui manipule des données sensibles, c'est juste obligatoire, surtout si elle swappe rarement, il est très possible sans ça de retrouver dans la partition de swap des données qu'on n'a pas envie d'y retrouver, et ce, un an après qu'elles y aient été écrites.

Si tu utilises un ramdisk de taille fixe pour /tmp, sur une machine qui reboote rarement, faut pas oublier d'avoir un mécanisme qui fait le ménage dans ce répertoire de temps en temps, parce qu'un /tmp plein, ça peut foutre en l'air plein de trucs... le paquet Debian tmpreaper, par exemple, nettoie régulièrement les vieux fichiers dans ce répertoire ; testé depuis deux ans, et approuvé.