Comments 30
Для luks не нужно ничего переустанавливать, и lvm не обязателен.
Поверхностное гугление выдало пару инструкций. Но судя по комментариям после одной из них компьютер уходил в цикличную перезагрузку, ну а вторая просто не работала. Пришлось идти на гитхаб проекта и читать документацию.
Чёта стрёмно как-то... Но спасибо за способ
Пользовался и ecruptfs, и encfs, перешел потом на LUKS отдельного раздела с точечным монтированием в разные места. Но предложенный вариант c fscrypt пожалуй интересней будет. Спасибо!
Шифрование только домашней папки это только видимость безопасности т.к. некоторые критические куски данных могут находиться за её пределами - разные настройки чего-либо системного, /tmp с каким-то странными штуками внутри, своп и так далее. Гораздо более безопасно в этом плане шифрование всего дискового раздела целиком.
во вторых я не хотел целиком шифровать весь диск
Ну, говоришь одно, а подразумеваешь другое. Не факт, что именно "не хотел".
Не могу знать наверняка, что было в голове автора, но предполагаю, что реальная мотивация далека от "не хотел". Возможно он всё-таки не хотел переустанавливать систему ради простого включения шифрования всего диска одной галочкой при установке убунты, а можно ли включить конкретно этот тип шифрования на уже установленной системе поленился разбираться. Плюс, как кажется на первый взгляд, все стоящие шифрования данные лежат в домашнем каталоге (нет, конечно). Плюс в шифрование одного каталога можно относительно безопасно "поиграться", а шифрование всего системного раздела - это вряд ли операция из серии "ошибся - ничего не испортил, не понравилось - легко отменил", поэтому эксперименты без острой необходимости ставить тупо стрёмно.
Тем не менее, вопрос включения шифрования на уже установленной системе для всего винта - актуален и интересен. Напр. в облаке запуская сервер ты получаешь ту же убунту уже установленной, причём - без шифрования. И задумываешься об этом недостатке когда на сервере уже много чего установлено и он активно используется… Так что если вдруг кто хочет написать аналогичную статью, только про шифрование всего винта - это было бы полезно. :)
Swap действительно может слить чувствительные данные, но swap часто вообще отключают, или он без проблем шифруется сессионным ключом. /tmp нынче почти везде смонтирован в память и на диск не попадает никогда. А где ещё на обычном десктопе могут оказаться важные данные, я как-то придумать не могу. Список установленных пакетов и время последнего включения я секретными данными не считаю: те, кому надо прятать даже такое, на ноуте с собой такую систему не носят.
docker volumes? всякие snap/flatpak хз где что держат, не факт, что в домашнем каталоге всё. Ну и плюс лично я терпеть не могу, когда /tmp автоматом удаляется при перезагрузках - и я такой не один. Плюс нередко докупаются дополнительные винты т.к. места не хватает. Это сходу пока речь о рабочей станции. А когда речь заходит о сервере, то там любой системный сервис может иметь (или сам быть) БД с критичными данными.
Но суть не в конкретных кейсах и их распространённости, а в том, что когда речь заходит о безопасности всегда предпочтительнее в принципе не задумываться о том, что нужно шифровать, а что можно вроде бы я почти в этом уверен и не шифровать наверное но не факт.
А, и забыл самый смешной кейс: когда системный раздел не зашифрован, то всегда есть возможность туда подложить кейлоггер, который поможет выяснить пароль от зашифрованной части когда наивный юзер загрузится с этого системного раздела.
И для всего этого нужно ноутбук незаметно украсть, поковыряться в нём и так же незаметно вернуть, чтобы владелец не узнал. А если ноут не в сети, то потом ещё раз украсть. Если есть возможность это провернуть, то есть и возможность встроить малварь в GRUB. Тогда уж нужно ещё и закрывать настройки UEFI, включать Trusted Boot, генерировать свой сертификат, регистрировать его в UEFI, подписывать им GRUB, ядро и все дополнительные дрова вроде Nvidia - а про всё это речи ни разу не было. Правда, теперь можно просто сбросить память на материнке, раз устройство в руках злоумышленника. Далеко не факт, что пользователь заметит, что ему сбросили системные настройки и переустановили GRUB. Значит нужно ещё подпаяться программатором к мультиконтроллеру и перенастроить его так, чтобы он сдох, если чексуммы не сойдутся. Правда, мультиконтроллер можно перепаять. Всё, фантазия кончилась.
Как видите, от варианта когда ноутбук физически побывал в руках злоумышленника и был незаметно возвращён, нельзя защититься внутри самого ноутбука. Поэтому я такой вариант и не рассматриваю.
И для всего этого нужно ноутбук незаметно украсть, поковыряться в нём и так же незаметно вернуть, чтобы владелец не узнал.
Вопрос шифрования винта в принципе актуален только когда уже есть возможность доступа к выключенному компу. Поэтому вопрос с "незаметно украсть" мы не рассматриваем - данное условие уже выполнено. И не обязательно именно украсть, вполне можно добраться до чужого устройства когда владелец отвлёкся/отошёл, (пере)загрузить его со своей флешки (которая автоматически добавить тот же кейлоггер на системный раздел). Факт перезагрузки владелец, конечно, может заметить - если комп вообще был изначально включен, - но скорее всего спишет на глюк, а даже если и заподозрит что-то, то почти гарантированно это не остановит его от ввода пароля от зашифрованного каталога.
А если ноут не в сети, то потом ещё раз украсть.
Это тоже не проблема: во-первых редкое устройство не в сети, и во-вторых раз удалось получить физический доступ один раз - получить второй раз скорее всего тоже получится.
Если есть возможность это провернуть, то есть и возможность встроить малварь в GRUB.
Возможно так и есть. Но технически это явно будет сложнее.
Тогда уж нужно ещё и закрывать настройки UEFI, включать Trusted Boot,
генерировать свой сертификат, регистрировать его в UEFI, подписывать им GRUB, ядро и все дополнительные дрова вроде Nvidia - а про всё это речи ни разу не было.
В тот момент, когда мы начинаем беспокоиться о шифровании винта - да, обеспечить защиту на уровне "до загрузки системы" скорее всего тоже нужно. Но тут я не до конца уверен - зависит от того, есть ли возможность встроить код для перехвата пароля от зашифрованного раздела на этом уровне и насколько это сложно/заметно.
Значит нужно ещё подпаяться программатором к мультиконтроллеру
Мне сложно оценить корректность/осмысленность данной идеи. Но такая атака определённо намного сложнее в реализации - как в плане требуемой квалификации исполнителя так и в плане незаметности её проведения и количества требуемого на неё времени. Грубо говоря когда владелец ноута сидя в кафе отошёл в туалет оставив ноут лежать на столе - что-то в нём перепаять вряд ли получится до возвращения владельца. Но на случай если в нашей оценке рисков такой риск необходимо учитывать некоторые материнки умеют определять факт вскрытия корпуса и сигналить об этом (впрочем, если мы уже дошли до паяльника, то наверное можно этот датчик тоже отключить, да и всю материнку тогда уже заменить целиком можно).
Как видите, от варианта когда ноутбук физически побывал в руках злоумышленника и был незаметно возвращён, нельзя защититься внутри самого ноутбука. Поэтому я такой вариант и не рассматриваю.
Защититься на 100% невозможно ни от чего, в принципе. Защита - это всегда вопрос соотношения меча (усилий на атаку) и щита (усилий на защиту). Но и ставить ворота посреди поля тоже нет никакого смысла - защита должна быть не "для галочки", а такая, которая увеличивает затраты усилий на взлом до той границы, которая считается приемлемой по нашей оценке рисков для тех угроз, от которых мы считаем необходимым защищаться.
Шифрование диска по определению подразумевает, что от риска получения физического доступа мы считаем необходимым защититься. Нужно ли при этом защищаться от риска незаметного получения физического доступа - вопрос, безусловно, отдельный - это другой риск который надо оценивать отдельно. Но часто ответ на него "да" просто потому, что если тот же вор имеет возможность украсть устройство, то это автоматически означает, что он имеет возможность сунуть в него флешку и перегрузить устройство вместо того, чтобы красть его. Поэтому я такой вариант рассматриваю. :)
есть ли возможность встроить код для перехвата пароля от зашифрованного раздела на этом уровне
Модифицированный GRUB подкинет злостный драйвер прямо в ядро, если нет SecureBoot.
Допустим, юзер убежал в сортир. Что может случится.
Вариант 1: Убежал и не залочил комп. Юзер баран, никакое шифрование тут не поможет.
Вариант 1.1: Юзер залочил комп, но у него работает автозапуск с флешек. Системный администратор у юзера - баран. Никакое шифрование тут не поможет. Кстати, на Астра Линуксе пока экран залочен, похоже, udev встаёт на паузу - он вообще не распознаёт изменения в USB устройствах пока залочен. Не знаю, как с этим на нормальных линуксах.
вариант 1.2: Юзер залочил комп, но в блокировщике опять 0-day дырка. Шифрование опять не поможет никакое.
Вариант 2: Придётся перезагружать, но у юзера не стоит SecureBoot или пароль на настройки - подкидываем свою флешку с модифицированным GRUB, он заменяет собой системный, и при загрузке подкидывает кейлоггер в ядро либо записывает пароль при полнодисковом шифровании. Приходит юзер, вводит пароль, шифрование снова в пролёте.
Вариант 3: У юзера SecureBoot и пароль на GRUB и настройки. Без паяльника уже вообще никак.
Есть ещё вариации, связанные с гипотетическими уязвимостями. Но тема во всех одна: я не смог придумать сценарий, в котором полнодисковое шифрование защищает содержимое хомяка лучше, чем шифрование хомяка и свопа. Кроме сценария когда злоумышленник может разобрать систему, вставить диск в свою систему, изменить его, вставить диск обратно, и юзер ничего не заметит.
По вариантам 1 и 1.1 полностью согласен.
Вариант 1.2 - честно говоря проще 0-day использовать через браузер подкинув юзеру ссылку, чем через блокировщик. Я бы вопросы 0-day в контексте шифрования диска вообще не рассматривал.
SecureBoot для линуха организовать не так просто, к сожалению.
А вот пароль на Grub и настройки UEFI поставить легко, равно как и заблокировать в UEFI загрузку с посторонних устройств. И это необходимо сделать как только доходит до шифрования диска - всего или части, не важно.
Можно ли исключать риск изменения диска через подключение его к чужой системе - зависит от того, как вероятность такого риска оценивает конкретный пользователь. Лично я бы такое не исключал - да, за время "вышел в туалет" такое провернуть сложно, но есть много других ситуаций, когда рядом с компом кто-то чужой может находиться длительное время (начиная от "ночью в офисе" и заканчивая "комп временно изымали на экспертизу менты"). В случае с кафе и туалетом это проворачивается в стиле "ноут украли!… (через полчаса) о, смотрите, мы нашли Ваш ноут - столик был пуст, официантка решила что ноут забыли, и отнесла в подсобку, чтобы вернуть когда владелец за ним вернётся".
Своп и tmp можно и нужно, т.к. повсеместно используется ssd, вынести в рамдиск, например используя zram. Памяти сейчас много, работать будет быстрее.
Для критичных сервисов и flatpack-ов - данные части ПО загружаются после инициализации фс и их можно аналогично папке зашифровать. И этот метод, шифрации необходимых мест с различными ключами устойчивее единого шифрования, т.к. при общем шифровании будет много иметься данных шифрованных и открытых,т.е. можно распараллеливание поиска ключей с высокой надёжностью.
некоторые критические куски данных могут находиться за её пределами
Это уже юзеру решать, что у него критично и ради чего он шифрование затеял.
Если посмотреть в целом то не luks то не fscrypt не безопасный вариант, надежнее всего это правдопадобное отрицание, и доступно оно только через создание скрытой системы. Читаем veracrypt шифрование системы со скрытой системой. Если уж так вышло можете сообщить пароль от основной системы а там собственно нету ни чего( какие нибудь котики безобидные фотки свежая история браузера ) а для скрытой системы например использовать уже дополнительные методы безопасности USB токены, pim и и т.д
самый важный пункт забыли. предварительно потренироватся на виртуалке.
Т.е для дешифровки папки будет использоваться ваш пароль для логина в системе.
Но это же никак не защитит данные, в чем проблема условному специалисту в сервис центре при включении компа подправить конфиг в бутлоадере, запустить сессию под рутом и выставить нужный пароль для учетки?
Не знаю. Этот вариант если честно, я не продумывал. Надо будет завтра проверить этот вариант.
PS. Можно активировать пользователя root и задать ему пароль?
в чем проблема условному специалисту в сервис центре при включении компа подправить конфиг в бутлоадере, запустить сессию под рутом и выставить нужный пароль для учетки?
Рискну предположить, что для шифрования папки используется не хэш юзерского пароля а некий уникальный ключ, который хранится на диске в зашифрованном виде, и вот для его шифрования уже используется хэш пароля. В случае легитимной смены пароля происходит расшифровка ключа хэшем старого пароля и шифрование хэшем нового пароля. В случае простого сброса "пароля под рутом" ключ уже не расшифруется.
Так, или примерно так, работает шифрование папок в Windows и шифрование контейнеров в VeraCrypt (который бывший TrueCrypt).
По этой статье как-то делал : Шифрование в EXT4. How It Works?
ps Все прекрасно работает, но в какой то момент одна директория была утеряна.
Сколько не подбирал пароль - мимо. Не понятно - скорее всего забыл или ошибся.Ещё там усугубилось переносом диска на другую машину. И есть некая вероятность, что система на которой шифровалось была с 32 битным ядром, а потом перехало на 64.
А что не так с eCryptfs? По моему очень удобный инструмент для создания шифрованных разделов из папок, и поддерживается на уровне ядра, давно им пользуюсь для шифрования приватного раздела куда кидаю личные данные и кэш браузера. Вот инструкция есть, понятная и проверенная, работает все на ура, без глюков вообще... https://wiki.archlinux.org/title/ECryptfs_(Русский)
Ответ на этот вопрос от разработчиков fscrypt есть в самом начале их README: https://github.com/google/fscrypt#alternatives-to-consider
Шифрование домашней папки на Linux с помощью fscrypt