Стоит ли применять LUKS на SSD для хомяка?

Если не надоедает вводить пароль (а тебе придется ввести два пароля, если не использовать автовход), или считаешь нормальным хранить ключ на флешке/разделе, то разницы нет. cryptsetup benchmark, поможет выбрать правильный алгоритм, который будет быстрее даже теоретической скорости твоего SSD. Обычно aes-xts 256b самый оптимальный по качество/скорость.

Стоит. Использую сам. Брат жив, зависимость есть.

лучше сразу весь диск шифровать потому что например пароли пользователей в системе хранятся не в /home

Длительность использования? Как изменилось состояние? Что говорит сам SSD?

Уже давно прошли времена когда нужно было думать о ресурсе ssd, главное просто всякое говно не покупать.

Какие пароли пользователей? На вход в ОС? Ну узнаешь ты их пароли, и? Хомяк зашифрован, пароли в браузерах не хранят. Каков профит у тебя?

А у меня два шифрованных раздела. Мне норм.
А чтобы не вводить пароль 14 раз, сделал так:

$ cat /etc/conf.d/dmcrypt |grep -vE '^$|^#'
target='key'
source='/dev/sda2'
options='--timeout=20'

target='home'
source='/dev/sdb1'
key='/dev/mapper/key'

target='data'
source='/dev/sdc1'
key='/dev/mapper/key'

Я бы лучше вынес на отлельный разлел и подключал когда понадобится, всё равно не каждый день будешь смотреть порушку использовать зашифрованные файлы. Хомяка не вижу смысла шифровать.

Какие пароли пользователей? На вход в ОС? Ну узнаешь ты их пароли, и? Хомяк зашифрован, пароли в браузерах не хранят. Каков профит у тебя?

Может у тебя везде один пароль используется, я же не знаю, сам подумай что у тебя не в хомяке и нужно ли это шифровать, ну и вообще проще все зашифровать и просто не париться по этому поводу.

Это вариант, но хомячёк эстетически приятнее, там: Видео, Музыка, Документы... Можно конечно симлинками замутить, но это как-то топорно.

Не, пароли разные, длинные и совершенно рандомные, но я тебя понял.

например пароли пользователей в системе хранятся не в /home

Пароли пользователей в системе вообще не хранятся.

Кстати, а что с TRIM? Работает через шифрование?

У меня весь SSD под luks (исключение efi). В контейнере lvm: boot, root, swap, home and etc. В /etc/lvm/lvm.conf issue_discard -> 1, /etc/crypttab -> etc/crypttab luks,discard. Trim работает. Такая схема используется мной несколько лет, полет нормальный. Влияние luks на SSD не замечал.

/etc/crypttab

externaldrive         UUID=XXXXXXXXX-XXXX-XXXX-XXXX-XXXXXXXXX        none    luks

/etc/fstab

 /dev/mapper/home     /home              ext4    defaults,discard  0  2

Как выше не вариант? Нужно так? : /etc/crypttab

home    UUID=8c3ea242-7b75-41d2-93f9-75b3c65aaa74       none    luks,discard

Покажи /etc/fstab

У меня весь SSD под luks (исключение efi). В контейнере lvm: boot, >>root, swap, home and etc. В /etc/lvm/lvm.conf issue_discard -> >>1, /etc/crypttab -> etc/crypttab luks,discard. Trim работает. >>Такая схема используется мной несколько лет, полет нормальный. Влияние >>luks на SSD не замечал.

Забыл еще systemctl enable fstrim.timer :)

Пароли пользователей в системе вообще не хранятся.

в зашифрованном виде, мне казалось это очевидно.

defaults уже включает в себя relatime, поэтому это дублирование. хомяк и дата без discard? А как же Trim?

Т.е. --allow-discards ты используешь только один раз в момент

cryptsetup open --type=luks --allow-discards /dev/sdXY home

defaults уже включает в себя relatime, поэтому это дублирование.

Норм, можно сэкономить пару байт.

хомяк и дата без discard?

Там HDD.

У меня шифрованы только HDD. Опцию я в man cryptsetup подсмотрел. :)

В /etc/crypttab записать надо.

Т.е. вот?
/etc/crypttab

externaldrive         UUID=XXXXXXXXX-XXXX-XXXX-XXXX-XXXXXXXXX        none    luks,discard

man crypttab. В бибаянах вроде по другому как то, мож еще где тоже по другому.

Здесь пишут:

Besides the kernel option, it is also required to periodically run fstrim or mount the filesystem (e.g. /dev/mapper/root in this example) with the discard option in /etc/fstab. For details, please refer to the TRIM page.

For LUKS devices unlocked manually on the console or via /etc/crypttab either discard or allow-discards may be used.

В общем я так понял что можно так можно так, а вообще лучше и в /etc/fstab прописать discard, и в /etc/crypttab прописать allow-discards.

Пароли пользователей в системе вообще не хранятся.

в зашифрованном виде, мне казалось это очевидно.

Очень мне странно слышать такое от обладателя пяти звёзд.

Пароли ни в каком в виде не хранятся. Ни в открытом, ни в зашифрованном. Ни в Линуксе, ни в, простигосподи, Винде.

В /etc/shadow или в /etc/tcb/*/shadow хранятся хэши. Хэш-функция такова, что обратное преобразование, то есть восстановление пароля из хэша, невозможно.

спасибо капитан, это и называется пароли в зашифрованном виде, НГ вроде закончился, может пора заканчивать бухать?

Ворвусь в тред.

Поясните плиз за корупцию фс, если вдруг где-то сбоить начнёт диск(-и), что будет с данными? Какова разница по сравнению с теми же данными на той же фс но без шифрования? Имеется ввиду, что затраты времени на восстановление превышают ли время переустановки системы и расчихловки бэкапа?

спасибо капитан

Вольно, разойдись! Разрешаю закурить и оправиться.

это и называется пароли в зашифрованном виде

Это ни разу так не называется. Зашифрованное предполагает расшифровку. В отличие от хеширования.

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

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

если ты просто хочешь защитить данные, то лучше не шифровать всё подряд

Нет. Шифрование должно быть только полным ― иначе не уследишь ни за временными файлами, ни за ошибками («сначала сохранил в другой каталог, потом открыл криптодиск, и только потом скопировал в криптодиск, а shred дернуть забыл»).

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

когда надо - подключаешь encfs и работаешь. потом размонтировал - и всё, оно зашифровано, лежит себе в файлике, который можно бэкапить, если нужно.

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

А ошибки они на то и ошибки (примеры с потолка) ― может и сборка собраться не в ту директорию, которая вне encfs, и банально пробел в cp добавить, что файл не туда улетит ― вариантов тысячи.

каких превьюхах? какие интимные фотки? я про ценные файлы и про разработку. твои фотки не нужны никому, я подозреваю.

при нормальной работе ничего никуда не «улетает» и лишние пробелы сами собой нигде не появляются. пользуюсь много лет на работе и дома и всегда удобно и практично.

каких превьюхах? какие интимные фотки? я про ценные файлы и про разработку. твои фотки не нужны никому, я подозреваю.

Знаешь что такое «пример»? Так вот ― это был именно он.

Хочешь другой пример? Текстовые редакторы могут сохранять бэкапы в .config/blabla.

И таких тысячи. Если в конкретном случае такого не случится, то нужно помнить, что люди шифруют далеко не только исходники (документацию, например), используют не только некий редактор X, который точно никуда ничего не сливает, и вообще, быть может, никак не связаны с разработкой.

при нормальной работе ничего никуда не «улетает»

Рано или поздно человек совершает ошибку. Кем бы ты ни был, какой бы у тебя ни был опыт, или, быть может, профессиональная паранойя ― ты все равно когда-нибудь совершишь ошибку.

Если есть возможность значительно снизить риски при незначительном падении производительности (отмечу, что с AES-NI шифрование работает быстрее, чем скорость чтения/записи на твердотелые накопители), то этим нужно пользоваться.

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

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

Кажется, ты не понимаешь, для чего превентивные меры.

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

Что верно, то верно. Если используется SSD, то деградация производительности при чисто программном шифровании будет заметной. Но стоит отметить, что на старом ноутбуке с Celeron T3300 вместо процессора и HDD особых проблем с производительностью не ощущал.

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

Непонятный ― безусловно не станет! Только вот откуда такая уверенность, что тот софт, который «понятный» ― полностью тебе известен?

А то предложили человеку использовать контейнер. Он в нем будет хранить какую-нибудь документацию, и не догадываться о том, что libreoffice бэкапы делает в ~/.config/libreoffice/4/user/backup. Или, к примеру, решит попробовать конфиг Spacemacs ― кто может дать 100% гарантию самому себе, что проверка пути к бэкапам придет в голову в этот момент?

при желании всё это настраивается. и пути к бэкапам, и само существование бэкапов.

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

Ты осознаешь что из всех кто прочитал этот тред ты единственный гений который не понял о чем я написал?)

Это ни разу так не называется. Зашифрованное предполагает расшифровку. В отличие от хеширования.

Которое предполагает перебор, и какая хрен разница в контексте данного треда?

в большинстве же случаев ломают не стоящий без хозяина на столе ноут, а через сеть.

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

ты полагаешь, что те, кто крадёт ноуты или берёт чужое, способны что-то ковырять? вряд ли. даже если бы они получили мой ноут со всеми данными, они бы не поняли, что это и зачем. и просто потёрли бы всё.

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

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

ты полагаешь, что те, кто крадёт ноуты или берёт чужое, способны что-то ковырять?

почему нет? ты думаешь они в 2017 году не знают что такое компьютер?

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

Я даже знаю о случаях шпионажа на работе когда руководителям было очень интересно читать скайпики и вконтактики своих работников что бы знать не собираются ли они увольняться или не кидают ли они его на деньги. Само собой это говноконторы в которых не стоит работать ни при каких условиях... тем не менее желающих хватает.

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

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

при желании всё это настраивается. и пути к бэкапам, и само существование бэкапов.

man human_factors. Я говорил о человеческих ошибках, которые неизбежны.

в большинстве же случаев ломают не стоящий без хозяина на столе ноут, а через сеть.

Пусть ломают. Задача шифрования в данном случае совсем не в этом.

ты полагаешь, что те, кто крадёт ноуты или берёт чужое, способны что-то ковырять? вряд ли. даже если бы они получили мой ноут со всеми данными, они бы не поняли, что это и зачем. и просто потёрли бы всё.

Очень наивно считать преступников недалекими.

ты думаешь они в 2017 году не знают что такое компьютер?

ну, тут какбэ нужно знать чуть больше, чем что такое компьютер :)

Я даже знаю о случаях шпионажа на работе когда руководителям было очень интересно читать скайпики и вконтактики своих работников что бы

знать не собираются ли они увольняться или не кидают ли они его на деньги.

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