Eliminar archivos de forma segura en el sistema de archivos btrfs

22

A veces, existe la necesidad de eliminar un archivo en un sistema de archivos y asegurarse de que el archivo haya desaparecido realmente. Un archivo que contiene contraseñas confidenciales, por ejemplo, debe eliminarse completamente del disco.

La emisión de un simple rmen un sistema de archivos típico elimina el inodo ("puntero") del archivo, pero no elimina el contenido del archivo en el disco físico; estos se dejan allí hasta que se sobrescriben cuando el sistema de archivos necesita espacio libre.

En muchos sistemas de archivos, el programa shred permite dicha eliminación segura. Sin embargo, en un sistema de archivos CoW como btrfs, este enfoque es inútil . El problema se exacerba por el hecho de que el archivo puede estar presente en las instantáneas de volumen.

¿Hay alguna manera de eliminar de forma segura un archivo en un sistema de archivos btrfs? ¿Es suficiente eliminar todos los punteros (en todos los volúmenes) y llenar el espacio libre con ceros ?

— goncalopp
fuente

2

Buena pregunta, no he pensado en ese tema antes. Una forma de solucionar ese problema sería cifrar dichos archivos. También puede cifrar todo el disco, pero si un atacante obtiene acceso de root al sistema en ejecución, eso no lo ayudará ...

— mreithub

@mreithub De hecho, encriptar tales archivos siempre es una buena idea en primer lugar, como lo es FDE. Sin embargo, no puede contemplar todos los casos de uso (un sistema incrustado, por ejemplo, aunque es discutible si dicho sistema estaría ejecutando btrfs de todos modos ...). Realmente estoy preguntando esto porque olvidé configurar el cifrado antes de copiar archivos confidenciales, pero me gustaría evitar borrar toda la partición

— goncalopp

9

La eliminación segura es una propuesta difícil en cualquier sistema de archivos. A menos que el sistema de archivos sea muy peculiar y garantice que no haya otras copias del archivo, debe limpiar todo el espacio libre en el dispositivo. Si bien es más probable que encuentre muchos bits del archivo en los sistemas de archivos de copia en escritura, aún más sistemas de archivos "estáticos" no tienen esta garantía en la práctica, porque muchos archivos se editan, por lo que hay bits de versiones anteriores del archivo por ahí.

Tenga en cuenta que borrar con ceros es tan bueno como borrar con bytes aleatorios, y no necesita múltiples pases. Borrar con ceros dejó datos residuales que podrían recuperarse parcialmente en condiciones de laboratorio con las tecnologías de disco duro de 1980; Esto ya no es aplicable hoy. Vea ¿Por qué es mejor escribir ceros (o datos aleatorios) en un disco duro varias veces que hacerlo una sola vez?

Puede deshacerse de los datos confidenciales de texto sin cifrar cifrando todo en el disco. Configure un volumen ecryptfs sobre ese sistema de archivos y mueva todos sus archivos (confidenciales) a él. Luego sobrescriba todo el espacio no utilizado del sistema de archivos. Puede borrar la mayor parte llenando el sistema de archivos cat /dev/zero >zero. Todavía puede quedar algo de información en bloques incompletos (bloques que contienen el último fragmento de un archivo, seguido de algo de basura, que podrían ser restos de un archivo confidencial). Para asegurarse de que no haya bloques incompletos, mueva todo en el sistema de archivos a ecryptfs (los archivos de ecryptfs usan bloques completos, al menos en configuraciones típicas donde los bloques son de 4kB). Asegúrese de aplicar esto a todos los volúmenes y de borrar todas las instantáneas que contengan datos confidenciales de texto sin formato.

Todavía puede quedar algo de información en el diario. No sé cómo fregar eso.

En SSD, debido a la reasignación de bloque, puede que queden datos que no se puedan leer por medios normales de software pero que se puedan recuperar pirateando el firmware o con acceso físico. Allí, su único recurso es borrar completamente el SSD.

— Gilles 'SO- deja de ser malvado'
fuente

3

Los ceros tienen la desventaja de que pueden comprimirse u omitirse por completo (un SSD puede TRIMAR en lugar de escribir ceros, ya que los sectores TRIM'd devuelven ceros cuando los lee). Eso hace que los ceros sean inseguros hoy en día. El uso de datos aleatorios obliga al sistema de archivos y al disco a escribir los datos tal como están.

— frostschutz

@frostschutz ¿Escribiría cualquier carácter que no 0sea correcto, y no esté sujeto a CORTE, digamos escribir todo 1en su lugar? ¿O algunas unidades usan compresión en todo?

— Xen2050

@frostschutz Si está llenando un volumen ecryptfs con ceros (que es lo que pensé que la respuesta está proponiendo aquí, sin embargo, en una inspección adicional, veo que su redacción es realmente ambigua), entonces escribirá esencialmente al azar (no compresible / no comprobable) datos al disco, ¿no?

— JamesTheAwesomeDude

@JamesTheAwesomeDude No, estaba proponiendo escribir los ceros en la parte sin cifrar, pero mencioné que esto no era suficiente en un SSD más abajo.

— Gilles 'SO- deja de ser malvado'

6

Hmmm, btrfs parece derrotar todos los métodos habituales de trituración ...

Hay una opción de montaje llamada nodatacowpero que no parece afectar a los archivos ya existentes.
Como ya tiene archivos sensibles en su disco, esta entrada de preguntas frecuentes de btrfs tampoco lo ayudará.
Entonces hay debugfs. Es solo para sistemas de archivos ext, pero hay un parche que podría funcionar. Puede usarlo para averiguar las direcciones de bloque afectadas y luego sobrescribirlas directamente en / dev / sdXY. Pero eso es muy peligroso y podría no funcionar (especialmente si hay más instantáneas del archivo)
Escriba un parche btrfs que le permita a uno modificar (o destruir) instantáneas específicas o un archivo completo
El intento más limpio (para datos realmente muy sensibles) sería:
- compre otro disco (a menos que tenga suficiente espacio libre para una copia de la partición afectada en el primero)
- configurar el cifrado de disco completo y sus sistemas de archivos en él
- copia todo del disco aa b
- arrancar en el sistema b y triturar todo el disco a ...
Este podría no ser el enfoque más barato, pero teniendo en cuenta los bajos costos de almacenamiento actuales y el problema que tendría con las otras opciones, en realidad podría ser el más barato (en términos de horas de trabajo).

— mreithub
fuente

nodatacowestablece el estado predeterminado de la Cbandera para los archivos recién creados . ¿Seguramente uno podría justo chattr +C ~/.browser/logins.sqlitey luego shred?

— JamesTheAwesomeDude

-6

Hay shred(1)para Unix / Linux (debe estar en los paquetes de su distribución). Es lo que recomienda el EFF .

— vonbrand
fuente

3

Si vuelves a verificar la pregunta, verás que mencioné triturar y por qué no es suficiente para el trabajo

— goncalopp

Todo lo que encuentro son sugerencias para usar el cifrado de archivos confidenciales, por la razón que mencionas.

— vonbrand

2

"En muchos sistemas de archivos, el programa shred permite una eliminación tan segura. Sin embargo, en un sistema de archivos CoW como btrfs, este enfoque es inútil". También hay dos enlaces allí.

— goncalopp