Utiliser `shred` depuis la ligne de commande

Je dois effacer certains fichiers en toute sécurité. J'ai utilisé shredsur les systèmes Linux auparavant, alors j'ai regardé autour de moi et j'ai constaté que cela shredfait partie de lacoreutils paquet dans macports. Je l'ai fait port install coreutilspour installer coreutils, mais je ne trouve toujours pas shreddans la ligne de commande.

Comment puis-je shredtravailler sur la ligne de commande de mon mac? Si cela compte, j'utilise Mac OS X 10.7.5 (Lion)

macos macports secure-erase

— inspecteurG4dget
source

Notez que la sécurité shreddépend du système de fichiers utilisé, je ne sais pas dans quelle mesure il est efficace sur HFS.

— Flimm

shred n'est pas efficace sur les systèmes de fichiers journalisés, c'est pourquoi il n'est pas disponible. Les MRS ont également été jugés non efficaces. Supprimez simplement normalement et prier semble être le seul espoir des systèmes de fichiers journalisés hfs +

— Kevin Johnson

Vraiment?! Pourriez-vous s'il vous plaît parler de pourquoi ce n'est pas efficace?

— inspectorG4dget

Les systèmes de fichiers journalisés enregistrent les modifications qui seront apportées avant l'écriture sur le disque. Il peut être utilisé pour récupérer des fichiers endommagés ou récupérer des données que vous souhaitez avoir détruites. Voir en.wikipedia.org/wiki/Journaling_file_system

— Alex Mooney

Réponses:

port install coreutilsajoute un préfixe ag aux noms des fichiers binaires, donc shred est /opt/local/bin/gshred.

— Lri
source

brew install coreutilsrend gshreddisponible pour ceux qui utilisent Homebrew.

— davidjb

OSX a une commande intégrée srmpour supprimer des fichiers en toute sécurité. Voir https://developer.apple.com/legacy/library/documentation/Darwin/Reference/ManPages/man1/srm.1.html . Vous pouvez également utiliser rm -Ppour écraser les fichiers trois fois avec des séquences d'octets.

Avec sierra ou ultérieur, macOS ne comprend plus srm. Mais les utilisateurs peuvent l'installer avec homebrew:

brew install homebrew/dupes/srm && brew link --force homebrew/dupes/srm

— Lily Hahn
source

Bien sûr, mais shred me permet de définir le nombre de remplacements. Ces outils ne le font pas. Des idées sur la façon d'obtenir cette fonctionnalité?

— inspectorG4dget

+1 excellente réponse. Je ne savais pas que la srmcommande existait. Il écrase, renomme et tronque le fichier avant de le supprimer. Cela, ajouté aux 7 passes conformes au DoD américain (0xF6, 0x00, 0xFF, aléatoire, 0x00, 0xFF, aléatoire) (option -m) garantit que le fichier est irrécupérable.

— Tulains Córdova

À partir de macOS Sierra, srmn'est plus inclus.

— Y3SCH

Les utilisateurs de macOS peuvent installer srmavec la commande brassée brew install homebrew/dupes/srm.

— hd.deman

homebrew/dupesest maintenant obsolète. Semble quesrm été supprimé et n'a pas migré vers homebrew-core.

— davidjb

La réponse de @ user495470 est correcte pour la question posée. Le problème est ni srmnishred vraiment un sens pour les systèmes modernes.

Ceci est principalement dû aux SSD. Contrairement aux disques magnétiques, les disques modernes compatibles TRIM effacent automatiquement les données supprimées en arrière-plan.

Les disques SSD effectuent également un nivellement d'usure. Cela rend les tentatives de "réécriture" d'un fichier à la fois vaines (l'écriture dans un emplacement physique différent) et indésirables (contribuant inutilement à l'usure du disque).

TRIM est activé sur tous les Mac équipés d’un SSD.

L'autre problème concerne le système de fichiers, en particulier les systèmes de fichiers journalisés, qui peuvent conserver une copie des données ailleurs avant leur écriture.

Même sur un support magnétique, cela peut poser des problèmes à la fois srm:

Tous les utilisateurs [..] doivent savoir que srm ne fonctionne que sur les systèmes de fichiers qui écrasent les blocs en place. En particulier, cela ne fonctionnera PAS sur [..] la grande majorité des systèmes de fichiers journalisés.

Et shred:

[..] shred repose sur une hypothèse très importante: que le système de fichiers écrase les données en place. [..] de nombreux systèmes de fichiers modernes ne répondent pas à cette hypothèse. Les exceptions comprennent: les systèmes de fichiers journalisés ou structurés en journaux [..]

Les volumes HFS Plus sont journalisés par défaut depuis Mac OS X v10.3.

De nos jours, le meilleur moyen de sécuriser les fichiers "supprimés" est d'activer FileVault (pour ne jamais écrire un disque non crypté), puis de les supprimer et de laisser TRIM le trier.

Si, par malchance, vous utilisez un support magnétique, désactivez la journalisation et, pour une raison quelconque, vous ne pouvez pas chiffrer le disque, vous disposez des options suivantes:

Utiliser rm -Pce qui écrase les fichiers avec 0xff, puis0x00 , puis 0xffencore
Installer coreutilspour gshred(ie.brew install coreutils && gshred secrets.txt )
srma été retiré de homebrew-dupeset homebrew-coremais quelqu'un a publié un robinet qui fonctionne (c.-à-d.brew install khell/homebrew-srm/srm && srm secrets.txt )
Destruction physique du médium :)

— Molomby
source

Mais je suppose que shred est toujours correct si vous déchiquetez toute la partition ou tout le disque.

— Konstantin

Tu veux dire comme shred /dev/hda? Oui, je suppose que oui. Les blocs adressés par le système d'exploitation restent toutefois soustraits de la mémoire physique et sont potentiellement remappés pendant la destruction. Je me demande si un nivellement d'usure et un espace de réserve sont des implémentations qui pourraient causer que cela ne fonctionne pas toujours.

— Molomby

+1 pour expliquer pourquoi le déchiquetage est inutile sur les SSD et la suggestion d'utiliser FileVault. APFS est-il journalisé ou savons-nous comment il gère la suppression de fichier? (Devrait probablement être un fil séparé!)

— Stuart H

Il semble y avoir l'hypothèse ici que la suppression sécurisée n'est nécessaire que pour les lecteurs «internes». Les lecteurs attachés sont sous toutes les formes et srm conviendrait pour certaines d’entre elles.

— Rondo