Shred: Non funziona su Journaled FS?

Question

La documentazione dello shred dice che il "brandello" non è "garantito per essere efficace" (vedi in basso). Quindi se distruggo un documento sul mio filesystem Ext3 o su un Raid, cosa succede? Devo distruggere parte del file? A volte distrugge tutto e qualche volta no? Può distruggere altre cose? Distrugge solo l'intestazione del file?

ATTENZIONE: Si noti che shred si basa su un presupposto molto importante: che il file system sovrascrive i dati sul posto. Questo è il modo tradizionale di fare le cose, , ma molti progetti di file system moderni non soddisfano questa ipotesi. I seguenti sono esempi di file di sistemi su cui brandello non è efficace, o non è garantito di essere efficace in tutti i file SYS tem modalità:

• sistemi di log-strutturati o file journal, come ad esempio quelli forniti con AIX e Solaris (e JFS, ReiserFS, XFS, ext3, etc.)

• file system che scrivono dati ridondanti e portano avanti, anche se alcune scritture falliscono, come ad esempio i file system RAID basati su

• di file sistemi che creano istantanee, come Network Appliance server NFS

• file system cache in sedi temporanee, come ad esempio la versione NFS 3 clienti

• file system compressi

Nel caso di file system ext3, validità di tale dichiarazione di non responsabilità (e shred ha quindi un'efficacia limitata) solo nella modalità data = journal , che aggiorna i dati del file oltre ai soli metadati. In entrambe le modalità data = order (default) e data = writeback, shred funziona come al solito. Le modalità di journaling di Ext3 possono essere modificate aggiungendo data = un'opzione delle opzioni di montaggio per un file system specifico nel file/etc/fstab, come documentato nella pagina man mount (man mount).

Answer 1

Tutto il brandello è sovrascrivere, svuotare, verificare il successo e ripetere. Non fa assolutamente nulla per scoprire se sovrascrivere un file porti effettivamente a sovrascrivere i blocchi che contenevano i dati originali. Questo perché senza conoscere cose non standard sul filesystem sottostante, non può.

Quindi, i file system di journaling non sovrascriveranno i blocchi originali sul posto, perché ciò impedirebbe loro di riprendersi in modo pulito dagli errori in cui il cambiamento è stato scritto a metà. Se i dati sono registrati su giornale, allora ogni passaggio di shred potrebbe essere scritto in una nuova posizione su disco, nel qual caso nulla viene triturato.

I file system RAID (a seconda della modalità RAID) potrebbero non sovrascrivere tutte le copie dei blocchi originali. Se c'è ridondanza, è possibile distruggere un disco ma non gli altri, oppure potresti scoprire che passaggi diversi hanno influenzato dischi diversi in modo tale che ogni disco è parzialmente distrutto.

Su qualsiasi file system, l'hardware del disco stesso potrebbe rilevare un errore (o, nel caso del flash, applicare il livellamento dell'usura anche senza un errore) e rimappare il blocco logico in un altro blocco fisico, ad esempio che l'originale sia contrassegnato come difettoso (o non usato) ma mai sovrascritto.

I file system compressi potrebbero non sovrascrivere i blocchi originali, poiché i dati con cui le sovrascritture di shred sono casuali o estremamente comprimibili su ciascun passaggio e uno potrebbe causare la modifica radicale delle dimensioni compresse del file e quindi la ricollocazione. NTFS memorizza piccoli file nella MFT, e quando shred arrotonda il filesize su un multiplo di un blocco, la sua prima "sovrascrittura" tipicamente causerà il trasferimento del file in una nuova posizione, che verrà quindi distrutta inutilmente lasciando il piccolo Slot MFT intoccato.

Shred non è in grado di rilevare nessuna di queste condizioni (a meno che non si disponga di un'implementazione speciale che si rivolge direttamente al driver fs e block). Non so se esistano effettivamente tali elementi). Ecco perché è più affidabile se usato su un intero disco piuttosto che su un filesystem.

Shred non distrugge mai "altre cose" nel senso di altri file. In alcuni dei casi sopra descritti, distrugge blocchi non allocati in precedenza invece dei blocchi che contengono i tuoi dati. Inoltre non distrugge alcun metadata nel filesystem (che suppongo sia ciò che intendi per "header del file"). L'opzione -u tenta di sovrascrivere il nome del file, rinominando un nuovo nome della stessa lunghezza e quindi abbreviando un carattere alla volta fino a 1 carattere, prima di eliminare il file. Puoi vedere questo in azione se specifichi anche -v.

Answer 2

La preoccupazione è che i dati possano esistere su più di un posto sul disco. Quando i dati esistono esattamente in una posizione, il brandello può "cancellare" in modo deterministico tali informazioni. Tuttavia, i file system che journal o altri file system avanzati possono scrivere i dati del file in più posizioni, temporaneamente, sul disco. Shred - dopo il fatto - non ha modo di saperlo e non ha modo di sapere dove i dati potrebbero essere stati temporaneamente scritti su disco. Pertanto, non ha modo di cancellare o sovrascrivere quei settori del disco.

Immagina: scrivi un file su disco su un file system journaled che esegue la revisione non solo dei metadati ma anche dei dati del file. I dati del file vengono temporaneamente scritti nel diario e quindi scritti nella posizione finale. Ora usi il brandello sul file. La posizione finale in cui sono stati scritti i dati può essere tranquillamente sovrascritta con shred. Tuttavia, shred dovrebbe avere un modo per garantire che anche i settori del journal che contengono temporaneamente il contenuto del tuo file vengano sovrascritti per essere in grado di promettere che il tuo file non è veramente recuperabile. Immagina un file system in cui il diario non è nemmeno in una posizione fissa o di una lunghezza fissa.

Se si utilizza la distruzione, si sta tentando di garantire che non sia possibile ricostruire i dati.Gli autori di brandelli sono onesti che ci sono alcune condizioni al di fuori del loro controllo in cui non possono dare questa garanzia.

Answer 3

Le altre risposte hanno già fatto un buon lavoro per spiegare perché il brandello potrebbe non essere in grado di svolgere correttamente il proprio lavoro.

Questo possono essere riassunti come:

brandello funziona solo su partizioni, non i singoli file

Come spiegato nelle altre risposte, se a distruggere un singolo file:

• lì non è una garanzia che i dati effettivi siano realmente sovrascritti, perché il filesystem può inviare scritture allo stesso file su diverse posizioni sul disco
• non c'è g garanzia che il fs non ha creato copie dei dati altrove
• il fs potrebbe anche decidere di "ottimizzare" le tue scritture, perché stai scrivendo ripetutamente lo stesso file (la sincronizzazione dovrebbe impedire questo, ma ancora una volta: nessuna garanzia)

Ma anche se si sa che tua filesystem non fare nessuna delle cose brutte di cui sopra, si deve anche considerare che molte applicazioni creano automaticamente copie di dati del file:

• file di ripristino incidente quali word processor, editor (come vim) ecc. scriveranno peri camente
• miniatura/file di anteprima in manager di file (a volte anche per non imagefiles)
• file temporanei che molte applicazioni utilizzano

Così, a corto di controllare ogni singolo binario che si utilizza per lavorare con i vostri dati, potrebbe essere stato copiato a destra, lasciato il centro & senza che tu lo sappia. L'unico modo realistico è quello di distruggere sempre le partizioni (o dischi) completi.