Supprimer en toute sécurité des fichiers sur le système de fichiers btrfs

22

Parfois, il est nécessaire de supprimer un fichier dans un système de fichiers et de s'assurer que le fichier a vraiment disparu. Un fichier contenant des mots de passe sensibles, par exemple, doit être complètement effacé du disque.

Émettre un simple rmsur un système de fichiers typique supprime l'inode ("pointeur") du fichier, mais il ne supprime pas le contenu du fichier sur le disque physique - ceux-ci sont laissés là jusqu'à ce qu'ils soient écrasés lorsque le système de fichiers a besoin de l'espace libre.

Sur de nombreux systèmes de fichiers, le programme shred permet une telle suppression sécurisée. Cependant, sur un système de fichiers CoW tel que btrfs, cette approche est inutile . Le problème est exacerbé par le fait que le fichier peut être présent sur les instantanés de volume.

Existe-t-il un moyen de supprimer en toute sécurité un fichier sur un système de fichiers btrfs? Est-il suffisant de supprimer tous les pointeurs (sur tous les volumes) et de remplir l'espace libre avec des zéros ?

filesystems security data-recovery btrfs goncalopp
la source
2
Bonne question, je n'ai jamais pensé à ce problème auparavant. Une façon de contourner ce problème serait de crypter ces fichiers. Vous pouvez également crypter l'intégralité du disque, mais si un attaquant obtient un accès root au système en cours d'exécution, cela ne vous aidera pas ...
mreithub
@mreithub En effet, le cryptage de tels fichiers est toujours une bonne idée en premier lieu, tout comme FDE. Il ne peut cependant pas envisager tous les cas d'utilisation (un système embarqué, par exemple - bien qu'il soit discutable qu'un tel système exécute de toute façon btrfs ...). Je pose la question parce que j'ai oublié de configurer le cryptage avant de copier des fichiers sensibles, mais j'aimerais éviter d'effacer toute la partition
goncalopp

Réponses:

9

La suppression sécurisée est une proposition difficile sur n'importe quel système de fichiers. Sauf si le système de fichiers est très particulier et garantit qu'il n'y a pas d'autres copies du fichier qui traînent, vous devez effacer tout l'espace libre sur l'appareil. Bien que vous soyez plus susceptible de trouver de nombreux bits du fichier sur des systèmes de fichiers en copie sur écriture, encore plus de systèmes de fichiers «statiques» n'ont pas cette garantie dans la pratique, car de nombreux fichiers sont modifiés, il y a donc des bits d'anciennes versions de la fichier qui traîne.

Notez que l'effacement avec des zéros est aussi bon que l'effacement avec des octets aléatoires, et vous n'avez pas besoin de plusieurs passes. L'effacement avec des zéros a laissé des données résiduelles qui pourraient être partiellement récupérées dans des conditions de laboratoire avec les technologies de disque dur des années 1980; ce n'est plus applicable aujourd'hui. Voir Pourquoi l'écriture de zéros (ou de données aléatoires) sur un disque dur plusieurs fois est-elle meilleure que de le faire une seule fois?

Vous pouvez vous débarrasser des données confidentielles en texte clair en chiffrant tout sur le disque. Configurez un volume ecryptfs sur ce système de fichiers et déplacez-y tous vos fichiers (confidentiels). Remplacez ensuite tout l'espace inutilisé du système de fichiers. Vous pouvez en effacer la plupart en remplissant le système de fichiers avec cat /dev/zero >zero. Il peut encore y avoir des informations dans des blocs incomplets (blocs qui contiennent le dernier morceau d'un fichier, suivis de quelques ordures - qui pourraient être des restes d'un fichier confidentiel). Pour vous assurer qu'il n'y a pas de blocs incomplets, déplacez tout sur le système de fichiers vers ecryptfs (les fichiers ecryptfs utilisent des blocs entiers, au moins sur les configurations typiques où les blocs font 4 Ko). Assurez-vous de l'appliquer à tous les volumes et d'effacer tous les instantanés contenant des données confidentielles en texte brut.

Il y a peut-être encore des informations dans le journal. Je ne sais pas comment frotter ça.

Sur SSD, en raison de la réaffectation des blocs, il peut y avoir des données qui ne peuvent pas être lues par des logiciels normaux mais qui peuvent être récupérées en piratant le micrologiciel ou avec un accès physique. Là, votre seul recours est un essuyage complet du SSD.

Gilles 'SO- arrête d'être méchant'
la source
3
Les zéros ont l'inconvénient de pouvoir être compressés ou entièrement omis (un SSD peut TRIM au lieu d'écrire des zéros, car les secteurs TRIM'd renvoient des zéros lorsque vous les lisez). Cela rend les zéros dangereux de nos jours. L'utilisation de données aléatoires force le système de fichiers et le disque à réellement écrire les données telles quelles.
frostschutz
@frostschutz Est-ce que l'écriture d'un caractère autre que 0correct, et non soumis au TRIMing, dirait que tout est écrit à 1la place? Ou certains lecteurs utilisent-ils la compression sur tout?
Xen2050
@frostschutz Si vous remplissez un volume ecryptfs avec des zéros (c'est ce que je pensais que la réponse propose ici, bien que, après une inspection plus approfondie, je vois que sa formulation est en fait ambiguë), alors vous écrirez essentiellement au hasard (incompressible / imbattable) des données sur le disque, non?
JamesTheAwesomeDude
@JamesTheAwesomeDude Non, je proposais d'écrire les zéros dans la partie non chiffrée, mais j'ai mentionné que cela ne suffisait pas sur un SSD plus loin.
Gilles 'SO- arrête d'être méchant'
6

Hmmm, btrfs semble vaincre toutes les méthodes de déchiquetage habituelles ...

  • Il existe une option de montage appelée nodatacowmais qui ne semble pas affecter les fichiers déjà existants.
  • Comme vous avez déjà des fichiers sensibles sur votre disque, cette entrée de la FAQ btrfs ne vous aidera pas non plus.
  • Ensuite, il y a debugfs. C'est seulement pour les systèmes de fichiers ext mais il y a un correctif qui pourrait fonctionner. Vous pouvez l'utiliser pour trouver les adresses de bloc affectées, puis les remplacer directement sur / dev / sdXY. Mais c'est très dangereux et pourrait ne pas fonctionner (surtout s'il y a plus d'instantanés du fichier)
  • Écrire un patch btrfs qui permet de modifier (ou de détruire) des instantanés spécifiques ou un fichier entier

  • La tentative la plus propre (pour les données vraiment très sensibles) serait de:

    • acheter un autre disque (sauf si vous avez suffisamment d'espace libre pour une copie de la partition affectée sur la première)
    • configurer le chiffrement complet du disque et vos systèmes de fichiers dessus
    • tout copier du disque a vers b
    • démarrer dans le système b et déchiqueter le disque entier a ...

    Ce n'est peut-être pas l'approche la moins chère, mais compte tenu des faibles coûts de stockage actuels et des problèmes que vous auriez avec les autres options, cela pourrait en fait être la moins chère (en termes d'heures de travail).

mreithub
la source
nodatacowdéfinit l'état par défaut de l' Cindicateur pour les fichiers nouvellement créés . Certes, on pourrait juste chattr +C ~/.browser/logins.sqliteet ensuite shred?
JamesTheAwesomeDude
-6

Il y en a shred(1)pour Unix / Linux (devrait être dans les packages de votre distribution). C'est ce que recommande l'EFF .

vonbrand
la source
3
Si vous revérifiez la question, vous verrez que j'ai mentionné shred, et pourquoi ce n'est pas suffisant pour le travail
goncalopp
Tout ce que je trouve, ce sont des suggestions pour utiliser le cryptage des fichiers sensibles, pour la raison que vous mentionnez.
vonbrand
2
"Sur de nombreux systèmes de fichiers, le programme shred permet une telle suppression sécurisée. Cependant, sur un système de fichiers CoW tel que btrfs, cette approche est inutile.". Il y a aussi deux liens.
goncalopp