:4u: FreeBSD 5.3 криптование /var

Belansky · Отправлено: **08:18, 30-12-2004** | #2

Slepoi Pju
А по-подробнее. Чего Вы конкретно хотите добиться?

Профиль · Отправлено: **16:22, 30-12-2004** | #3

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

В итоге имеем закриптованые логи, БД, и прочую информацию, которая хранится в /var.
Тоесть, если загрузка ОС происходила без желания владельца то /var будет фальшивым, но при этом работа всей ОС в целом не нарушится.

mar · Отправлено: **17:35, 30-12-2004** | #4

а такой огород совершенно необходимо городить? Просто chmod 640 или 750 на соответствующие файлы-каталоги не спасет?

archy · Отправлено: **20:07, 30-12-2004** | #5

И до кучи на раздавать свои криптостойкие пароли никому!

Профиль · Отправлено: **23:53, 12-01-2005** | #6

chmod не подойдет. Если диск снять и подмаунтить на другой ОС, то - хоть chmod 000.
Нужно криптовать

mar · Отправлено: **00:52, 13-01-2005** | #7

Slepoi Pju

Цитата:

Если диск снять и подмаунтить на другой ОС,

ну... тогда ставим серверную стойку в сейф, закапываем в землю, заливаем бетоном и на подступах организуем небольшое минное поле

А если серьезно, то если информацию надо так охранять, то бежать надо из админов этого сервака без оглядки, бо самое некрипто-шифрованное звено самой защищенной сети это человек. И примите добрый совет - не надо лказываться на месте этого человека. Или интерес чисто академический?

misher · Отправлено: **13:11, 13-01-2005** | #8

Такая тема делается через геом.
Но криптование будет не сверх стойким (стойкое требует много ресурсов, да и нестойкое с акстивно работающей БД неслабо пригрузит систему)
Ну а насчет фальшивого var оно это надо? Ведь такую штуку влет "выкупят"
Вообщем следует нераз подумать надо ли это делать и если решились:
http://www.freebsd.org/doc/en_US.ISO...ncrypting.html

Профиль · Отправлено: **16:54, 13-01-2005** | #9

и академичесский - тоже
но еще и лень переносить БД

mar · Отправлено: **18:01, 13-01-2005** | #10

Slepoi Pju
ага, это уже ближе к делу. Если речь идет о БД, то почитайте (по ссылке misher и в гугле), обращая внимание на большие проблемы со скоростью доступа, использование специальных и недешевых ускорителей и т.д. При том, что работа с СУБД сама по себе требует немалых ресурсов.

Slepoi Pju Сообщения: n/a	Профиль \| Цитировать chmod не подойдет. Если диск снять и подмаунтить на другой ОС, то - хоть chmod 000. Нужно криптовать
	Отправлено: 23:53, 12-01-2005 \| #6

Slepoi Pju Сообщения: n/a	Профиль \| Цитировать и академичесский - тоже но еще и лень переносить БД
	Отправлено: 16:54, 13-01-2005 \| #9