Re: Effacer ses fichiers de façon sécurisée
On Mon, Dec 02, 2002 at 05:32:23PM +0100, Nicolas C. wrote:
> J'aimerai savoir pourquoi ça ne fonctionne pas avec les systèmes de
> fichiers journalisés et s'il existe un remplacement fiable à shred
> pour l'Ext3.
Dans ext2, un fichier est composé d'une liste de secteurs
sur disque. Quand tu rallonges le fichier, le système
allonge la liste. Quand tu ré-écris par dessus le début du
fichier, le système ré-utilise les même secteurs.
shred (je suppose... je connais pas shred, mais je
connaissais un truc équivalent pour DOS) va donc réecrire
n'importe quoi par dessus tout le fichier avant de
l'effacer. Comme ça, les secteurs sont remplis de n'importe
quoi. (Dans le cas normal, la liste des secteurs est
détruite et les secteurs sont marqués comme libres, mais les
données sont toujours là... d'où problème de sécurité,
encore que ça se discute: il faudra avoir accès en root à
/dev/hdax, et dans ce cas il y a des façon plus simples de
voler des données confidentielles. Mais bon, le cas se
défend pour des supports amovibles).
Je ne suis pas sûr comment ext3 marche dans le détail, mais
de façon générale, les systèmes de fichier journalisés
tentent de conserver la cohérence. C'est à dire: si tu
commence à réecrire le début d'un fichier, et il y a une
panne de courant, tu veux que ton fichier contienne soit
l'ancienne version, soit la nouvelle _terminée_, mais pas un
mélange des deux (ce qui arrive avec ext2 ou FAT).
Donc, le système commence par écrire les nouvelles données,
puis _ensuite_ change la liste des secteurs qui compose le
fichier. Bien évidement, il devient alors impossible de
réecrire sur le _même_ secteur du début de fichier... et le
principe de shred ne marche pas.
De façon (presque) graphique:
On a un fichier qui est constitué d'une suite de secteurs:
32 -> 56 -> 24 -> 78
Si tu réécrit le début du fichier, ext2 réecrit dans le
secteur 32. Mais ext3 alloue un nouveau secteur:
32 -> 56 -> 24 -> 78
41
puis écrit dans le secteur, puis met à jour la table du
fichier:
32 /-> 56 -> 24 -> 78
41/
Et finalement libère l'ancien:
41 -> 56 -> 24 -> 78
Il suffirait que ext3 ré-écrive 32 pour que le problème ne
se pose pas...
/Y
[Attention: je ne sais _pas_ comment ext3 marche, c'est ce
que je suppose sachant comment ext2 et JFFS marchent. En
fait, ça m'étonnerait que ça se passe exactement comme ça,
car les fichiers se fragmenteraient beaucoup. C'est l'idée
qui compte...]
Reply to: