http://www.thc.org/releases.php?q=delete&x=0&y=0

пойдет?

Хм вроде пач на ядро был на эту тему даже на кернел орг где то валяется.

PS: А на flash памяти он также затирать будет ? )

cat /dev/null > file && rm file

этого мало.

Спасибо!

еще в rsbac тоже такая фича есть

Обычно во всех дистрибутивах есть программка shred

fopen fwrite .. ZERO, ZERO, ZERO .... fclose unlink

че ентот Subj приципился ...

че ентот Subj приципился ...

DoD 5220.22-M

http://www.cerberussystems.com/INFOSEC/products/docusec3.htm

fopen
for (int i=0; i< 3; i++) {
fwrite "\0\1\0\1\0\1\0\1", "\0\1\0\1\0\1\0\1" ....
// flash disk cache?
rewind
fwrite "\1\0\1\0\1\0\1\0", "\1\0\1\0\1\0\1\0" ....
// flash disk cache?
}

rewind
fwrite // "ANSI X9.17c keystream"? ....
//" and the final overwrite is read-back verified" ?
// flash disk cache?
fclose
unlink

кто-нибудь подскажет как "раскоментировать" ;-)

flush disk cache

From http://seclists.org/lists/linux-kernel/2003/Dec/3114.html
"Linux uses mount/unmount command to flush disk cache. "

Я прочитал соответствующие части DoD 5220.22-M (можно посмотреть тут: http://www.dss.mil/isec/nispom_0195.pdf и, самое интересное, тут: http://www.cerberussystems.com/INFOSEC/stds/sanitize.htm ).

Прямо скажем, он меня не впечатлил.

Во-первых, там не учитывается архитектура дисков, поэтому вышеприведенный "псевдокод" вовсе не соответствует стандарту. Точнее, стандарт пишет "Overwrite all addressable locations with a character, its complement, then a random character and verify." Это хорошо, но, там же - "TTHIS METHOD IS NOT APPROVED FOR SANITIZING MEDIA THAT CONTAINS TOP SECRET INFORMATION." - во-вторых, данные могут оставаться "на границах" дорожек, поскольку запись на диск, в сущности, аналоговая.

За обсуждением этого аспекта, думаю, стоит обратиться к файлику usenix6-gutmann.doc, который есть в архиве secure delete, ссылку на который я уже давал.

Не собирается, при кмпиляции вот такая ошибка:

gcc -O2 -D_FILE_OFFSET_BITS=64 -D_LARGEFILE_SOURCE -D__KERNEL__ -DMODULE -fomit-frame-pointer -fno-strict-aliasing -pipe -mpreferred-stack-boundary=2 -I/lib/modules/`uname -r`/build/include -c sdel-mod.c
sdel-mod.c:22:25: asm/smplock.h: No such file or directory
sdel-mod.c: In function `smash_it':
sdel-mod.c:197: error: `O_RDWR' undeclared (first use in this function)
sdel-mod.c:197: error: (Each undeclared identifier is reported only once
sdel-mod.c:197: error: for each function it appears in.)
sdel-mod.c:302: error: `O_WRONLY' undeclared (first use in this function)
sdel-mod.c:302: error: `O_TRUNC' undeclared (first use in this function)
sdel-mod.c: In function `wipefile':
sdel-mod.c:322: error: `MOD_INC_USE_COUNT' undeclared (first use in this function)
sdel-mod.c:324: warning: assignment makes pointer from integer without a cast
sdel-mod.c:337: error: `PATH_MAX' undeclared (first use in this function)
sdel-mod.c:380: error: `MOD_DEC_USE_COUNT' undeclared (first use in this function)
make: *** [sdel-mod.o] Ошибка 1

Походу она не совместима с ядрами 2.6 ??

> Походу она не совместима с ядрами 2.6 ??

Я не удивлюсь, если на 2.6 его еще не портировали. Попробуй попинать автора.

> sdel-mod.c:22:25: asm/smplock.h: No such file or directory

а этот файл есть? все ошибки - это просто отсутствие различных констант, причем O_RDWR, O_WRONLY, O_TRUNC - точно относятся к файловым операциям, PATH_MAX - максимальная длина пути. MOD_INC_USE_COUNT и MOD_DEC_USE_COUNT используются для регистрации модулей и беглый grep по сорцам показывает, что в 2.6 оно тоже никуда не делось.

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

Привет oxonian,
посмотрел sources http://www.thc.org/releases.php?q=delete&x=0&y=0

The deletion process is as follows:

1. The overwriting procedure (in the secure mode) does a 38 times
overwriting. After each pass, the disk cache is flushed.
2. truncating the file, so that an attacker don't know which
diskblocks belonged to the file.
3. renaming of the file, so that an attacker can't draw any conclusion
from the filename on the contents of the deleted file.
4. finally deleting the file (unlink).

Все тоже самое "... и так 38 раз ..." (btw, 38? ;-)

Тем болеее, ни слова о "во-вторых, данные могут оставаться "на границах" дорожек, поскольку запись на диск, в сущности, аналоговая"

Марк Ковкин

Привет++,
там в sources есть usenix6-gutmann.doc,
который рассказывает, почему "... и так 38 раз ..."

Марк Ковкин

++
usenix6-gutmann.doc

9. Conclusion

Data overwritten once or twice may be recovered by subtracting what is
expected to be read from a storage location from what is actually
read. Data which is overwritten an arbitrarily large number of times
can still be recovered provided that the new data isn't written to the
same location as the original data (for magnetic media), or that the
recovery attempt is carried out fairly soon after the new data was
written (for RAM). For this reason it is effectively impossible to
sanitise storage locations by simple overwriting them, no matter how
many overwrite passes are made or what data patterns are written.

поэтому нужно обеспечить чтобы диска касались только зашифрованные данные..

38 раз - это некоторое (возможно - срежнепотолочное) число перезаписи, которое позволит заодно разрушить данные на границах дорожки. Хотя, почему-то у меня есть ощущение, что в Гутмане это объясняется, не помню.

Привет,
"все дело в ...", что hard disk drivers используют
компрессию (RLE или др.), читай zippping on hardware level.
т.е. когда пишешь 255 раз по 1, на самом деле записываются не 225 "ячейки",
а только 2 == "255 раз по 1", т.е остальные 253 "ячейки"
остаются нетронутыми, что невозможно прочитать програмно, но легко "железно".
Товаришч из статьи пытался найти алгоритм, как "обмануть"
compression, чтобы "портились" все ячейки. Отсюда "итак 38 раз ...",
потому что он брал наиболее вероятные/популярные виды компрессии
используемые в hard disk drivers .
Очевидно, что алгоритм hardware compression зависит от производителя
(к сожалению не отечественного ;-) и реально подобрать
универсальный алгоритм, который бы портил/терел на все 100% для любых
drivers/hard disks невозможно.
По-видимому такая задача должна решаться на "harware level".

Марк Ковкин

> компрессию (RLE или др.)

RLE - это все-таки не сжатие, а кодирование.

Что касается чтения данных с границ дорожек, видимо я про это читал еще где-то.

> По-видимому такая задача должна решаться на "harware level".

Ну, в упомянутом стандарте и сказано, как.

oxonian,
"Кавказ - это и здравница, и житница ..."
тожe самое и про RLE - это и сжатие, и кодирование ;-)

Марк

Интересно, а что мешает файловой системе оптимизировать запись в файл таким образом, чтобы записываемая информация пишется не поверх старой информации, а в соверщенно новое место?

Например, какая-нибудь оптимизирующая fs может обнаруживать, что мы пытаемся записать 512 байт в файл длиной 512 байт и, вместо того, чтобы записывать их поверх старого содержимого, "передвинуть" указатель на содержимое файла поближе к началу диска и записать информацию уже туда.

В этом случае 38 (или даже 38000) перезаписей не спасут. И придётся разбираться с форматом хранения файлов у разных файловых систем + писать отдельное безопасное удаление для этих фс.

Я не утверждаю, что существующие fs именно так _делают_, но они (или будующие fs) вполне _могут_ так делать.