Регистрацияloop-aes & gpg (ядро 2.6.12 и выше)
Есть Линукс по соседству с виндой и ещё одной малоизвестной ОС, хард поделённый на разделы.
Линуксу отведены несколько разделов под б-м крупные каталоги, в том числе boot, root, swap, tmp.
Как организовать шифрование всех разделов ( т.е. включая загрузочный (если можно), корневой и swap разделы) Линукса с помощью loop-aes и интеграцией с gpg?
Вопрос очень объёмный, так что приветствуются любые ответы и советы.
Начиная от параметров конфигурации ядра, до конкретных инструкций по утилитам.
И в итоге неплохо бы это собрать в HOWTO, по рунету порыскал, есть кое-что, но для старых ядер по-моему, как здесь к примеру.
комментариев: 44 документов: 3 редакций: 0
И далее:
После чего следует позаботиться о том, чтобы до монтирования криптотома ни одна программа не пыталась получить доступ до размещённых на нём каталогов. Пример почерпнут из ExitTheMatrix HOWTO. Ссылка на последний была приведена на HiddenWiki сети Tor; в HOWTO были приведены и вспомагательные скрипты, рекомендации и пр. Увы, и этот метод – всё ещё не то, что Вам нужно... Я сам буду с удвоенным интересом следить за развитием данной темы :)
Практиковал недавно полное шифрование дискового слайса FreeBSD средствами geom_bde и geom_eli (с использованием флэш-карты в качестве второго фактора аутентификации – "то, чем владеет пользователь"), если добьюсь упеха в этом деле, обещаю поделиться опытом на Wiki.
P. S. Да, ещё один, скорее справочного характера, материал вот: http://silinio.webhost.ru/crypt-discs.html
комментариев: 9 документов: 1 редакций: 0
Кстати, на счёт шифрования boot раздела, на сколько это целесообразно?
А на счёт моего линукса, если надо будет, то переставлю, пока там ничего стоящего нет.
Целесообразность шифрования /var целиком для меня тоже сомнительна, ценность могут предствалять лишь логи и наверное база данных файловой системы (slocate, host ids – если они установлены). Но и эти данные хранить не обязательно
– журналирование на рабочей станции можно просто отключить
– если лог все таки бывает нужен, можно его хранить на tmpfs (который в свою очередь будет в зашифрованном swap) только в течении сеанса работы.
– индексацию зашифрованных разделов необходимо отключать в любом случае, это касается и slocate и host ids.
Итого получаем что в шифровать имеет смысл swap, /home и возможно (но необязательно) часть /var
А зачем?
1) Ради интереса и опыта полезного в дальнейшей работе.
2) Проверить этот способ, стабильность там и т.д.
3) Ну скажем так, я параноик, и не хотел бы, чтобы дядьки разные не смогли узнать, чем я там хитрым занимаюсь :) (А я и незанимаюсь, просто – параноик, но дядькам же об этом не обязательна знать, правильно? ;) )
Вообще хотелось бы сделать безопасную рабочую станцию на базе Gentoo. Конечно лучше бы Open BSD, но ушлости мне пока не хватает, и с портированием будут напряги. А для развлечений выньда пока устраивает.
paranoid ant, ну как, удовлетворил любопытство? :)
От блин пароль зобыл, ничего, что я гостем пока?
[offtopic]Блин, я вот как-то узнал, что унас дисеры через таких дядек проходят, хрустно-хрустно стало. Тупасть совковая[/offtopic]
Это означает, что фс контейнера должна быть не журналируема, или фс на которой находится контейнер должна быть не журналируема?
Чего-то расшифровать сей пункт невмочь, помогоите, а?
комментариев: 44 документов: 3 редакций: 0
При шифровании дискового раздела средствами dm-crypt или geom_{bde, eli} систем Linux и FreeBSD, зашифровывается ведь содержимое самого раздела, а файл-контейнер как таковой не создаётся. Файл устройства /dev/mapper/cryptfs в таком случае предоставляет доступ к plaintext-содержимому, а /dev/hdxN – к ciphertext. Иными словами, данные нисколько не защищены в то время, когда смонтирован раздел. Имеется в виду та ФС, что создаётся на /dev/mapper/cryptfs (кстати в вышеуказанном примере создаётся ext3 – журналируемая ФС :!: ).
комментариев: 9 документов: 1 редакций: 0
комментариев: 9 документов: 1 редакций: 0
На порядок? Или меньше?
Просто есть мысль, что можно ограничиться шифрованием /tmp и swap в моменты необходимости.
А делами достойными наибольшей засекреченности заниматься уже внутри, допустим, vmware, расположив его virtual hd в зашифрованном разделе.
комментариев: 44 документов: 3 редакций: 0
Мне самому интересно, почему в примере использована журналируемая ФС... Впрочем, если журналируются только метаданные (в reiserfs, к примеру, по умолчанию происходит именно так), не думаю, чтобы журналирование представляло большой риск.
По поводу шифрования свопа, Mell, видели ли Вы эту тему: http://pgpru.com/forum/viewtopic.php?t=1116?
Кстати похоже, что loop-aes действительно гораздо предпочтительнее, чем dm-crypt, вот любопытная цитата из nlo.lists.linux-crypto по этому поводу:
[quote:9e8ccb8090="Phil H"]
Loop-aes is still regarded as by far the best civilian partition encryption scheme available for linux. Developmentally and in terms of bug fixes is is way ahead of dmcrypt.
Loop-aes developer Jari Rassu has been at pains to point this out – I strongly suggest you search this list for his comments on dmcrypt and truecrypt. Truecrypt, which is also device-mapper based, only very recently attempted to fix a major security hole which Jari had been warning people about for some time.
The rise of dmcrypt is perhaps largely because Fedora has decided it's the thing to go with. Why? Perhaps because it's seen to be "easier to use", because the loop-aes readme insists that a kernel recompile is necessary => "no newbies please". However the debian packages for loop-aes do not require a kernel recompile unless you want to encrypt the root filesystem. (But I overreach my level of expertise. The person to talk to here might be Max, the maintainer of the debian loop-aes packages. He is a regular on this list). If you look at some of the "serious" security-oriented livecds ie knoppix-STD and INSERT, you'll see they ship with recent versions of loop-aes – not dmcrypt.
I don't want to disparage any efforts in this direction and I really hope dmcrypt and truecrypt continue to improve, but if you look at the dmcrypt wiki the project doesn't inspire confidence in me. I mean, loop-aes has a venerable history. Also, truecrypt cannot yet make containers under linux – it can only mount them.
Recently I was horrified when I read an article on root filesystem encryption on laptops in Linux Journal by an "expert" who, being a Fedora user, went with dmcrypt. The horrifying thing was this: his instructions used a *PLAIN TEXT single aes256 keyfile* – NOT EVEN a gpg-encrypted, multiline keychain. So your usb stick contains the key in plain text. An attacker gets hold of your usb stick, and game over. Yet it is a simple matter to use a gpg-encrypted key with dmcrypt – I've done it just to prove this.
I don't see how cryptLUKS or whatever it's called is any easier to use than loop-aes, once loop-aes is set up. In fact I find it confusing to use.
Just why has what is often regarded as an inferior encryption scheme been pushed? That in itself would make an interesting article.
Видимо, dm-crypt имеет и очевидную слабость – использование номера сектора в качестве вектора инициализации для режима CBC. Цитата из того же треда:
P. S. Может кому-то будет полезно, зеркало ExitTheMatrix HowTo в виде не-hidden сервиса: http://exitthematrix.dod.net/matrixmirror/index.html
комментариев: 44 документов: 3 редакций: 0
комментариев: 44 документов: 3 редакций: 0
комментариев: 21 документов: 2 редакций: 0