Запароливание, шифровка, скрытие каталогов/файлов (Ищу софт)

[gramozeka]

Мне вот действительно интересно, теоретически какие протоколы/ стандарты можно использовать для обмена ключами (паролями) для линукс-систем.

Реверс-инжинирингом эти протоколы в конце-концов "откроют", и будет вам pam-модуль.

а еще есть варианты аппаратного шифрования с тупо аппаратным ключом

Плохой вариант: потерял флешку-ключ, и плакали данные...

во раздули ...
а если самолет с президентом и "ядерным чемоданчиком" упадет в океан - все, пропала Россия ...
Самодисциплина и самоорганизация это не абстрактные термины , а вполне конкретные действия и методы которые прямо ведут необходимому результату , а дремучести(не побоюсь глупости) юзера не поможет никакой сверхпродвинутый софт и никакое самое навороченное железо (ИМХО).

[QWERTYASDF]

Не так. Нужно как минимум передать ключ (пароль) устройству, стандартный драйвер это вряд ли умеет.

В чем сложность передать небольшой ключ через сборку "стандартных" протоколов?

а еще есть варианты аппаратного шифрования с тупо аппаратным ключом

Это когда на лицевой панели девайса ключ (маленькую чипульку и/или набираешь код) вводишь что-ли?

[drBatty]

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

А для гостей можно спецучётку сделать. Там всё тоже самое, просто на своей учётке необходимо и достаточно убрать право доступа в некоторые каталоги. Если гости не имеют права загрузить другую ОС (например с LiveUSB) и/или украсть жёсткий диск - этого вполне достаточно.

Остальные вышеописанные варианты служат для совсем других целей.

[QWERTYASDF]

Доброе время суток.

История решения описанной в первом сообщении проблемы (в кавычках или нет - по вкусу) окончилась, как мне резонно советовали, настройкой нескольких пользователей с их правами. Теперь, т.к. переезжаю на ноутбук, который вполне реально могут украсть, проблема вернулась. Думаю, что мне нужна шифрованная ФС и я решила использовать дефолтное шифрование, предлагаемое debian-installer (т.к. ставлю эту систему в качестве основной рабочей). Есть несколько вопросов.

Вопрос 1. О выборе шифрования ФС вообще. Насколько ээ..юзабельное шифрование у debian-installer вообще? Ну, в плане наличия каких-нибудь неприятных багов, фич? Дело в том, что шифровать файлы решила твердо, но по знаниям относительно шифрования в Unix-е никуда не уехала относительно времени первого поста. Т.е. нужно, чтобы все работало из коробки. В Debian-е предлагается, вроде, по умолчанию dm-crypt - его и собираюсь использовать. Так-же, подумываю об использовании шифрованных LVM-томов. Остальные вопросы подразумевают использование этого dm-crypt.

Вопрос 2. Я периодически копирую важные данные rsync-ом на сменный носитель. Соответственно, хочется примонтировать его к шифруемому /home "обычным" способом (при помощи mount так, как было-бы и без шифрования) и получить шифрование/дешифрование записываемых/читаемых данных на лету. С этим не будет каких-нибудь проблем или не очевидных (для такого новичка, как я) настроек? Или может например команда монтирования будет требовать каких-то дополнительных параметров?

Вопрос 3. Например, в Debian_1 (установлена на один раздел на компе_1) шифрую /home и /home/usbdata (сменный носитель). Могу ли я в Debian_2 (установлена на другой раздел на компе_1) и/или в Debian 1_1 (установлена на компе_2) примонтировать/расшифровать эти разделы? Или же шифрованные таким образом разделы, читаются только в той инсталлированной ОС, в которой были зашифрованы?

Ну вот пока и все наверное...Буду благодарна за ответы.

[drBatty]

Теперь, т.к. переезжаю на ноутбук, который вполне реально могут украсть, проблема вернулась. Думаю, что мне нужна шифрованная ФС

а я вот так не думаю. Зачем вам шифрованная ФС? ИМХО всё равно расшифрованные файлы будут в памяти, тогда почему-бы там и не хранить весь /home/? Время от времени его можно сбрасывать в фоне в зашифрованный файл(без секретного ключа железки), но вот при загрузке придётся ввести пароль к секретному ключу для распаковке /home.

[QWERTYASDF]

Теперь, т.к. переезжаю на ноутбук, который вполне реально могут украсть, проблема вернулась. Думаю, что мне нужна шифрованная ФС

а я вот так не думаю. Зачем вам шифрованная ФС? ИМХО всё равно расшифрованные файлы будут в памяти, тогда почему-бы там и не хранить весь /home/? Время от времени его можно сбрасывать в фоне в зашифрованный файл(без секретного ключа железки), но вот при загрузке придётся ввести пароль к секретному ключу для распаковке /home.

Я чего-то не поняла

Зачем вам шифрованная ФС? ИМХО всё равно расшифрованные файлы будут в памяти, тогда почему-бы там и не хранить весь /home/?

В оперативной памяти или на винте? В любом случае, после выключения системы в памяти не будет не зашифрованных файлов на соответствующих разделах - это мне и надо.
Вероятно сама не правильно выразилась. "Шифрованная ФС" - имелось в виду именно шифрованные разделы /home и /var и все, что примонтируется к первому. Вы тоже про этого говорили или про что-то другое?

[drBatty]

Зачем вам шифрованная ФС? ИМХО всё равно расшифрованные файлы будут в памяти, тогда почему-бы там и не хранить весь /home/?

В оперативной памяти или на винте?

в оперативной памяти, которая RAM всё равно будут копии файлов в открытом виде. Я предлагаю /home/ сделать там же(в RAM). Однако, большие файлы оттуда вынести куда-нибудь в другое место на диске, и НЕ зашифровывать.

Как всегда ИМХО, потому-как у меня нет больших секретных файлов, а музыку пусть слушают...

[QWERTYASDF]

Зачем вам шифрованная ФС? ИМХО всё равно расшифрованные файлы будут в памяти, тогда почему-бы там и не хранить весь /home/?

В оперативной памяти или на винте?

в оперативной памяти, которая RAM всё равно будут копии файлов в открытом виде. Я предлагаю /home/ сделать там же(в RAM). Однако, большие файлы оттуда вынести куда-нибудь в другое место на диске, и НЕ зашифровывать.

Как всегда ИМХО, потому-как у меня нет больших секретных файлов, а музыку пусть слушают...

Не, не пойдет, RAM-ы (2 Гб) маловато будет мне.

Вы лучше подскажите насчет 2/3 вопросов моего поста выше. Меня сейчас более всего смущает вопрос, как я буду подмонтировать/отмонтировать к шифруемому /home свой внешний диск. Вот если на апельсинах совсем: Сейчас у меня внешний диск с "обычным" (незашифрованным) ext3 разделом, я его подключаю (командой mount) к шифро-/home - мне "на лету" должны предложить его отформатировать в шифро /home/data или например вот так его делать надо...Или как?...

[yars]

А зачем вам шифровать /home? Я там почти ничего не храню, вся всячина лежит на отдельном разделе, примонтировать и размонтировать раздел - дело нескольких секунд. Без знания пароля - дохлый номер, если, конечно, гость не гуру. Но среди знакомцев линуксоидов нет, они даже и не подозревают о том, что у меня все на отдельном разделе. Спрятать хорошо можно только на виду. Сделайте несколько разделов, примонтируйте их в подкаталоги хомяка, а тот самый крамольный раздел держите по умолчанию отмонтированным. Настройте sudo так, чтобы оно спрашивало пароль при попытке смонтировать тот самый раздел - все, никто даже и знать про него не будет. Хотя, если задача стоит защититься вообще от всех, то тут я, пожалуй, пас.

[QWERTYASDF]

yars

Всякие прикладные программы хранят всякую всячину в /home. А это и эскизы просмотренных изображений и все такое подобное. Вот поэтому и хочу сразу весь /home зашифровать. Во избежание.
И вообще исхожу из того, что у злоумышленника появится физ-доступ к винту или загруженная с live-cd ОС.

[/dev/random]

Вы лучше подскажите насчет 2/3 вопросов моего поста выше. Меня сейчас более всего смущает вопрос, как я буду подмонтировать/отмонтировать к шифруемому /home свой внешний диск. Вот если на апельсинах совсем: Сейчас у меня внешний диск с "обычным" (незашифрованным) ext3 разделом, я его подключаю (командой mount) к шифро-/home - мне "на лету" должны предложить его отформатировать в шифро /home/data или например вот так его делать надо...Или как?...

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

[drBatty]

Не, не пойдет, RAM-ы (2 Гб) маловато будет мне.

у меня 1Гб.

Без знания пароля - дохлый номер, если, конечно, гость не гуру.

а если гуру?

Всякие прикладные программы хранят всякую всячину в /home. А это и эскизы просмотренных изображений и все такое подобное. Вот поэтому и хочу сразу весь /home зашифровать. Во избежание.

это логично, но у меня там совсем немного получилось.

Да, вот HOWTO http://mirror.yandex.ru/slackware/slackwar...EADME_CRYPT.TXT

В принципе там ничего сложного нет. Даже шифрование свопа и корня тоже не очень запутанное.

[QWERTYASDF]

Да, вот HOWTO http://mirror.yandex.ru/slackware/slackwar...EADME_CRYPT.TXT

Ээ...а на русском нету? : )

[drBatty]

QWERTYASDF
ЕМНИП нет.

[QWERTYASDF]

В очередной раз решила подобраться к вопросу не без некоторых оснований считая, что этот раз окажется более успешным : )

Примерно, задача - шифровать на лету всю систему на своем ноутбуке. В перспективе - на Slackware с LVM. Как понимаю, нужно что-то на уровне ядра, шифрующее блочные устройства моих дисков. На досуге погуглила, появились некоторые наброски и вот связанные с ними вопросы:

Выбор loop-aes или dm-crypt? Если последнее, то с luks или без? Насколько успела почитать в инете - между указанными системами спор и как-то не ясно что таки лучше. Одни говорят, что loop-aes устарел и что с включением/эксплуатацией оного жуткие проблемы. Другие - что все нормально и скорость многократно выше.

[chitatel]

Примерно, задача - шифровать на лету всю систему на своем ноутбуке.

А зачем шифровать всю систему, да ещё и "на лету"? В /lib & /boot что-то жутко секретное будет?

[/dev/random]

А зачем шифровать всю систему, да ещё и "на лету"? В /lib & /boot что-то жутко секретное будет?

/boot как раз при "полном" шифровании не шифруется. Что-то всегда должно оставаться незашифрованным, что-то, что сможет спросить у пользователя ключ при загрузке. И это "что-то" обычно лежит в /boot. Иногда - на флешке, в этом случае и ключ можно положить туда же. А насчёт остального... При выборочном шифровании всегда есть риск утечки данных из зашифрованной области в незашифрованную (в логи, кеши, своп и так далее). Гораздо надёжнее шифровать всё.

[chitatel]

Гораздо надёжнее шифровать всё.

Хммм... И накладные расходы при этом?

P.S.
Не, если на ноутбуке секретные файлы государственного масштаба или гигабайты любимого прона - вопросов нет, это святое.

[QWERTYASDF]

Читала где-то, что мол шифровать все на уровне устройства по крайней мере несущественно медленнее нежели выборочное шифрование фс.

[Bizdelnick]

И накладные расходы при этом?

Расшифровка происходит всяко быстрее, чем чтение с HDD. Да и с SSD, наверное, тоже.

[chitatel]

Читала где-то, что мол шифровать все на уровне устройства по крайней мере несущественно медленнее нежели выборочное шифрование фс.

У меня интерес в своё время был не академический, а практический, и я использую шифрованные /home и swap на ноутбуках с Юбунтой. Думаю, что этого вполне достаточно для требуемого в моём случае уровня безопасности данных. Полагаю, что теряю что-то в плане отзывчивости/скорости загрузки/работы системы (в загрузке точно теряю), но с этим можно смириться. А при шифровании всей системы - печально было бы совсем.

[/dev/random]

Хммм... И накладные расходы при этом?

У меня винт при последовательном чтении держит около 110 МБ/с, это даёт 20% загрузку одного ядра из четырёх. Был бы SSD, может быть, шифрование и вызывало бы какое-то снижение производительности. А может, и нет. Но на обычном винте точно не снижает.

[Bizdelnick]

Полагаю, что теряю что-то в плане отзывчивости/скорости загрузки/работы системы

Почему бы не погонять тесты, например bonnie++, и не сравнить производительность ФС, а заодно и загрузку проца помониторить?

[QWERTYASDF]

Ну, /home и swap - мне для себя как-то кажется маловато. Мало изучала вопрос где какое приложение что хранит, но кажется, что далеко не только в /home. А даже если и так, то все-равно неприятно думать, что укравшие ноут смогут читать даже хотя-бы то, что у меня в /etc и в /usr/bin.

[Bizdelnick]

Я бы /var и /tmp обязательно к списку добавил. /etc можно зашифровать только вместе с корнем, иначе не получится. А что в /usr/bin может быть секретного?

[QWERTYASDF]

Я бы /var и /tmp обязательно к списку добавил. /etc можно зашифровать только вместе с корнем, иначе не получится. А что в /usr/bin может быть секретного?

Само собой. Ну а там у меня скрипты допустим самописные, в которых какие-то мои комментарии могут быть.

*******

Так что по сути вопроса то изначального? : )

[/dev/random]

Так что по сути вопроса то изначального? : )

В старом формате (loop-aes и dmcrypt без LUKS) пассфраза является ключом для шифрования данных, и её смена - долгий и опасный процесс, досрочное прерывание которого, преднамеренное или нет, приводит к потере данных. В LUKS внутренний ключ находится в заголовке и сам шифруется пассфразой или пользовательским ключом, что позволяет менять их мгновенно, без перекодирования всего содержимого. Для меня это было решающим фактором.

[Bizdelnick]

Ну а там у меня скрипты допустим самописные

/usr/bin — не самое подходящее для них место. Лучше в /usr/local/bin класть, если они всем юзерам должны быть доступны (а если нет — то в ~/bin).