Forum Linux.général Effacement sécurisé et système de fichier journalisé

Posté par  .
Étiquettes : aucune
0
6
fév.
2008
Bon, tout à l'heure en voulant regarder de plus près l'effacement sécurisé, je me suis rendu compte que celui-ci n'était pas du tout efficace sur des systèmes de fichier journalisés (comme Reiserfs).
En parcourant la toile, j'ai d'ailleurs pu vérifier sous une partition reiserfs ceci :
On créé un fichier texte avec quelques mots. On l'efface de manière sécurisé à l'aide de shred par exemple :
shred -uv -n 3 fichiertexte
Ensuite, un simple :
strings /dev/lapartition | grep unmotclé
renvoie bien quelque chose immédiatement (la première occurrence de la sortie du grep)
Bon apparemment, ce comportement est normal, c'est le principe de la journalisation.
Peut-on supprimer de manière ciblée les infos qu'on trouve avec ce grep ? Ou bien je pensais en reconstruisant l'arbre (option de reiserfsck) du système de fichier, faire disparaître ces infos... Bref, il y a moyen ou pas (sans formatage) ?

Comme solution, j'utilise le chiffrement avec encfs. J'ai testé : un fichier créé dans le coffre ouvert, puis refermé après, n'apparaît pas dans le grep ;)

  • # sync

    Posté par  . Évalué à 2.

    pour forcer les données encore en memoire à etre deposer sur le disque ?

    • [^] # Re: sync

      Posté par  . Évalué à 1.

      Je vote pareil...

      Le journal, c'est fait pour stocker les opérations, pas les fichiers, donc normalement shred devrait avoir éffacé le contenu.

      Par contre, pour un petit fichier il est très probable que les infos écrites par dessus soient encore dans le cache (de reiserfs) et pas sur le disque, d'où le résultat du grep...

    • [^] # Re: sync

      Posté par  . Évalué à 1.

      Oui, ça peut venir de cela. Mais ça peut aussi venir de reiserfs lui-même qui peut déplacer un fichier sur le disque sans rien dire.

      Un cas simple: Un petit fichier A peut se loger à la fin d'un bloc qui n'est pas totalement utilisé et partage donc ce bloc avec le fichier B. Si tu retouche le fichier B, notament en le grossissant un peu, le bloc devient trop petit pour les deux fichiers, reiserfs déplace donc ton fichier A dans un autre bloc. Si tu grossis ton fichier B de telle façon qu'il n'empiète que de 1 ou 2 octets sur le fichier A, alors ce fichier ne sera pas effacé de ce bloc et tu te retrouve avec deux copies dont une incomplète de ton fichier A.

      Fin bref, si tu dois renouveller cette opération, je te conseille de changer de système de fichier ou de l'utiliser avec l'option notail.

      • [^] # Re: sync

        Posté par  . Évalué à 1.

        Ok, merci pour vos réponses.
        J'envisageais effectivement (avant cette découverte) de changer de système de fichier (repasser à ext3). L'ennui, c'est que c'est la partition système ;)
        Qu'entends-tu par l'option notail ?
        Et pour le sync, je sais pas si l'option est dispo pour du reiserfs ?

        En tout cas, si je fais un grep de texte par exemple d'historique d'un navigateurs internet, on peut remonter assez loin...;) Et ces données ne sont pas dans le cache, l'exemple du fichier texte, c'était...pour l'exemple.
        Si je dois faire de temps en temps des montages avec certaines options pour virer ces infos, pourquoi pas ?

    • [^] # Re: sync

      Posté par  . Évalué à 2.

      Oui mais en faisant cela seul le dernier passage du shred sera effectivement écrit sur le disque (le seul qui reste dans le cache), pas les 34 (ou je ne sais plus combien) autres (à moins de faire un sync pendant le shred, mais ça devient plus ou moins aléatoire). Il faut donc ensuite recommencer plusieurs fois l'effacement sécurisé avec synchronisation.

      (à moins qu'un seul effacement convienne aux exigences de sécurité, mais souvent on estime qu'un seul passage est insuffisant).

      • [^] # Re: sync

        Posté par  . Évalué à 1.

        une rumeur laissait entendre qu'au dela du 8e passage cela ne servait pas à grand chose.

        en effet, à chaque fois que tu veux ecrire à un endroit, le disque decale legerement la tete.
        Il serait capable de faire cela 7 fois, avant de revenir à la premiere position.

        donc le faire 8fois reviens à le refaire sur la premiere zone (deja faite au passage 1)

  • # Bon...

    Posté par  . Évalué à 1.

    Impossible de me défaire de certaines métadonnées qui apparaissent toujours dans le grep en sortie du strings sur une partition.
    J'ai pourtant fais plusieurs redémarrage (donc démontage de partition) depuis pourtant...et j'ai cherché les fichiers dans lequel pouvait rester encore des traces : j'ai cru un moment avoir réussi puisque le grep renvoyait moins de chose, mais là c'est revenu...A croire que le système de fichier reiserfs fait ce qu'il veut avec les données.
    En gros, il est facile de récupérer des données de cookies de firefox avec ce système...malgré tous les effacements qu'on peut imaginer.
    J'ai regardé l'outils sync, mais ca n'a pas l'air de faire grand chose...
    Ce qu'il faudrait faire c'est monter la partition reiserfs avec des paramètres adéquat (quitte à le faire qu'une seule fois de temps en temps), personne n'a d'idée ? KiKouN signalait l'option notail ?

    Merci ;)

    • [^] # Re: Bon...

      Posté par  . Évalué à 1.

      Il se pourrait qu'il reste encore des fichiers en fait sur la partition.
      J'ai beau cherché, impossible de trouver un fichier qui contiendrait ça...
      J'ai déjà regardé tous les fichiers dans firefox, fais quelques grep par ci par là, mais rien...
      Le problème de strings, c'est qu'il ne dit pas à quel endroit il lit le flux de données...
      Mais comme je sais pas si ces infos sont dans un fichier ou pas, c'est plus dur...
      Il faudrait faire une recherche sur tous les fichiers du disque dur (ou du moins dans certains répertoires) qui contiennent tels chaîne de caractère... J'ai tenté avec un grep sur une sortie d'un cat, mais il me dit parfois que la liste d'arguments est trop longue...Bizarre non ?

  • # Un premier pas

    Posté par  . Évalué à 1.

    Bon il semblerait qu'un classique remplissage de zéro par la commande :
    dd if=/dev/zero of=fichier bs=1M
    Jusqu'à atteindre un taux presque plein de la partition, puis suivi d'un sync et enfin, de la suppression de fichier arrive à faire apparemment le ménage ! Ouf
    Faut que je continue à faire des essais mais à priori, c'est sur la bonne voie ;)
    Je suis en train de regarder la doc de secure-delete qui contient certains outils un peu plus évolué que shred :
    cf
    http://www.techthrob.com/tech/securedelete.php
    Notamment un outils permettant de nettoyer l'espace libre (comme la commande au dessus)

    Voilà, qu'en pensez-vous ?

Suivre le flux des commentaires

Note : les commentaires appartiennent à celles et ceux qui les ont postés. Nous n’en sommes pas responsables.