Exécution de shred sur un fichier en mémoire est inutile. Les données du fichier sont également susceptibles d'être présentes dans la mémoire de l'application, dans les caches, etc. à la sortie, car c'est plus rapide.
Bien sûr, il n'y a aucune garantie que le fichier peut être récupéré. Mais il n'y a aucune garantie que ce ne soit pas le cas non plus. Si votre modèle d'attaquant est que l'attaquant peut voir votre contenu RAM, vous devez vous occuper de beaucoup de choses. À tout le moins, vous devez effacer les pages RAM dès qu'elles sont libérées par le processus. Vous pouvez appliquer les correctifs Grsecurity au noyau Linux, au moins le PAX_MEMORY_SANITIZE option. Et vous devez faire attention aux processus en cours d'exécution et susceptibles de stocker des informations confidentielles. Et gardez à l'esprit que le noyau stocke également des informations confidentielles, telles que l'état RNG et les clés de chiffrement du disque. Le correctif TRESOR du noyau Linux protège les clés de chiffrement du disque pendant le fonctionnement normal, mais ce n'est pas une défense parfaite et je ne connais pas de correctif similaire pour l'état RNG.
Le danger que vous essayez d'atténuer est le journal du système de fichiers, c'est-à-dire shred n'est pas efficace sur les systèmes de fichiers qui ont un journal (par exemple, ext3, ext4, reiserfs).
En supposant que vous n'utilisez aucun unionfs pour la persistance (apparemment, vous pouvez le faire dans Tails bien que je n'ai jamais essayé), tout est stocké dans un tmpfs .
La documentation Linux sur tmpfs ne précise pas s'il effectue la journalisation. Pourtant, tmpfs est basé sur ramfs , le même système de fichiers que celui utilisé dans initramfs , et ce système de fichiers n'a pas de journal. Par conséquent, il est (plus ou moins) sûr de supposer que tmpfs n'a pas non plus de journal.
Sur un système de fichiers sans journal shred effectuera l'écrasement du fichier, ce qui le rendra difficile à récupérer avec des outils d'analyse (pratiquement impossible à récupérer à partir d'un vidage RAM). Puisque tout se passe dans des pages mémoire, et les inodes d'un tmpfs pointez simplement vers les pages mémoire, en utilisant shred est bien mieux car il pourra écrire dans ces pages mémoire.
Mise en garde
Ce qui précède fonctionne certainement de cette manière sur Tails et sur Knoppix. Cela fonctionnera probablement de la même manière sur presque toutes les distributions Linux sur LiveCD, y compris Kali Linux, mais il y a une mise en garde .
Cela fonctionne pour les fichiers ! La mémoire contiendra également la mémoire applicative, voir la réponse de Gilles sur la mémoire applicative. Sérieusement, regardez cette réponse, cela ouvre un point important.
De plus, une distribution basée sur Ubuntu Linux (qui peut ou non inclure Kali Linux * puisque son prédécesseur, Backtrack, était basé sur Ubuntu) montera tout échange qu'il trouve sur la machine qu'il démarre, ce qui peut laisser un vecteur d'attaque bien pire ! Données persistantes sur l'appareil lui-même !
Une autre mise en garde avec Kali Linux, c'est qu'il est livré avec metasploit et démarre le postgres base de données à utiliser avec metasploit . Postgres a sa propre journalisation (qui est basée sur les fichiers et non sur le système de fichiers), que vous voudrez peut-être aussi détruire (c'est-à-dire détruire les fichiers postgres et pas seulement supprimer les données via psql ).
* Kali n'est pas basé sur Ubuntu, il est basé sur Debian, mais je ne sais pas s'il a abandonné tous ses scripts de configuration depuis le moment où il s'appelait Backtrack et était basé sur Ubuntu