wipe, EXT3, гарантированное удаление

[Sam Stone]

Если кто пользовался сабжем, сколько проходов надо данной программе (ставится из одноименного пакета), чтобы гарантированно прибить файл на ext3? Если честно - тестить самому лень Вдруг кто уже проверял.
Еще меня смутила в мане следующая строчка:

Wiping over NFS or over a journalling filesystem (ReiserFS etc.) will most probably not work.

Крайний случай удаления не рассматриваем

The best way to sanitize a storage medium is to subject it to temperatures exceeding 1500K.  As a cheap alternative, you might use wipe at your own
       risk.

 

[Kwah]

http://wipe.sourceforge.net/

http://www.linux-kurser.dk/secure_harddisk_eraser.html :

So what you need to do is overwrite the whole harddisk several times with different patterns. Peter Gutmann recommends 35 passes with different patterns. The DoD 5220.22-M NISPOM recommends 3 passes.

Статья Peter Gutmann:
http://wipe.sourceforge.net/secure_del.html

[Sam Stone]

Тяжко после работы читать кучу нудного английского текста...
ну собсна предустановки на 35 (или около того) проходов есть подобных программах. Также говорится о затирании всего диска.
Хотелось бы узнать именно об удалении отдельных файлов с журналируемой ФС. Может кто сталкивался и поделится, пока я гуглю?..

[Nomadian]

Некторый оффтопик, хотя это, как посмотреть  .

100% удаление отдельного файла может рассматриваться как две разных задачи:
1. Уничтожение содержимого.
2. Уничтожения записи о файле.

Содержимое надо затирать до удаления файла. Затирать надо, записывая информацию по текущему размеру файла. При параноидальном подходе в те же 35 проходов. При совсем параноидальном - размер округляется вверх кратно размеру нода ФС.

Со вторым в Ext3 всё просто: достаточно переименовать файл перед удалением. Опять же для параноиков, можно и раз двадцать переименовать .

Мысли вслух:
Насколько я понимаю логику работы журналируемых ФС, журнал хранит только информацию о незаконченных операциях. То есть, стёр файл успешно - и вскоре запись в журнале будет удалена. Насколько "вскоре" вопрос сложный, но, по идее, при успешном размонтировании-монтировании ФС журнал должен очищаться.

При затирании файла надо не писать сразу, например, 35 паттернов, в один нод, а последовательно записывать все ноды первым паттерном, затем подавать команду flush и переходить ко второму и т.д. Причина - оптимизация записи контроллерами современных дисков. Если подать подряд несколько команд для записи одного сектора, скорее всего, выполнится только последняя, т.е. в худшем случае из 35 паттернов запишется лишь 35-й.

При использовании swap-раздела куски открытого файла теоретически могут выгружаться из памяти в swap, что также является вероятной уязвимостью.

При затирании только файла, а не всего диска, теоретически подвести могут а) оптимизирующие алгоритмы размещения нодов в ФС и б) перемещение секторов микроэлектроникой диска.
Первое объясняется работой дефрагментирующих алгоритмов ФС: данные активно перемещаются для обеспечения максимальной непрерывности цепочки нодов с файлом, при этом старые ноды не затираются, а просто помечаются свободными. Ещё "злее" ситуация в ReiserFS, построенной по принципу сбалансированного дерева. В ней информация перемещается ещё и для обеспечения максимальной усредненной скорости поиска следующего узла при чтении.
Причиной второго - перемещения секторов микроэлектроникой диска - могут стать выходы из строя секторов. Bad-сектор нередко нестабилен, но вполне читаем, а информация в нём остаётся. Скоро "огонька добавит" активно рекомендуемая производителями оптимизация использования поверхности на SSD носителях. Для обеспечения максимальной продолжительности жизни такого диска необходимо активно перемещать часто записываемые сектора на другие участки поверхности. Те участки, где такой сектор располагался, необходимо либо занимать редко модифицируемыми данными, что хорошо, либо "до последнего" не использовать. Именно существующие какое-то время копии редко модифицируемых секторов и, главное, "карантинные" участки станут причиной очередной головной боли для любителей секретности.

В общем, мысль про печку и 1500 С не столь уж сумасшедшая, если, конечно, предположить, что уничтожаемые данные того стоят. В остальных 99% случаев можно использовать wipe или шифрованную ФС. Кстати, учтите, что пароль к последней, скорее всего, "третьим лицам" будет проще "добыть" далеко не электронными и "неконституционными" методами  .

[antas]

сильно сказано
неудержался....

[axe]

В Ext3 есть 3 режима журналирования:
 * writeback
 * ordered
 * data
Они указываются при монтировании. Так вот, для wipe опасность представляет только третий режим, data, поскольку только в нем данные записываются в журнал. В двух других данные в журнал не попадают (только метаданные), а значит, эти режимы ничем не отличаются для wipe от ФС без журналирования.

По умолчанию Ext3 монтируется в режиме ordered, т.е. "безопасном" для Wipe.

Эта информация то ли с сайта Wipe, то ли с сайта Shred, то ли из man одной из этих программ.

Да, это, разумеется, все на уровне "файловая система и выше". Т.е. все подводные камни, описанные Nomadian, остаются

[Sam Stone]

Собственно wipe или srm, имеющиеся в репках, трут аналогично - забивают файл определенными шаблонами и/или 0/FF, каждую запись сопровождает sync(), в конце файл забивается рандомными данными, переименовывается в нечто рандомное, режется для скрытия реального размера и собсна удаляется. Т.е. делает все как надо. Посему хотелось бы отыскать некую золотую середину между скоростью удаления и параноидальным количеством проходов, возможно, зависящим от ФС. При этом пожалуй следует исключить особо извращенные и трудоемкие методы восстановления. Все-таки не чертежи боевого человекоподобного робота затираем А всего лишь нелицензионный дистрибутив венды

В Ext3 есть 3 режима журналирования:
 * writeback
 * ordered
 * data

А вот это уже полезное Про это я запамятовал. Остается разве что побороть свою лень и провести тесты по восстановлению вайпнутых за 1...10 проходов файлов

[Kwah]

Sam Stone
Я же приводил цитату... Там англ. но немного