Не так давно, по случаю, мне достался ноутбук. Скончался от болезни человек, с которым я был в хороших отношениях. Спустя какое то время родственники приятеля начали распродавать и раздавать имущество умершего. Мне отдали ноутбук. Ноут Acer, не особо новый и не дорогой, особой ценности не представляет, отдали бесплатно. Но попросили по возможности достать оттуда данные - старые фото и видео на память. На ноутбуке установлена десятка и учетка с паролем, которого никто не знал. Делаю загрузочную флешку, цепляю съемный диск. Готово. В процессе копирования посмотрел, что еще есть на диске. Текстовые файлы с паролями, профиль браузера, какая то рабочая документация, личные заметки и т.д. Ненужно и не интересно. Фото и видео отдал родственникам. Диск отформатировал. Ноут в кладовку.
Но в процессе ковыряния ноутбука, у меня появилась мысль. А хотелось бы мне, что бы в подобной ситуации кто то, так же лазил в моем ноутбуке. Нет, мне бы очень этого не хотелось. Несмотря на то, что там нет чего-то компрометирующего и критически важного для меня и моих близких. Все равно нет. Не приятно. А с учетом того, что мой ноутбук всегда и везде со мной. То я могу его где то забыть, потерять да и банальную кражу тоже никто не отменял. И если за свой телефон и планшет по этому поводу я не переживал, все таки там биометрия и шифрование, то ноутбук давал мне повод для беспокойства. Шифрования у меня там не было.
А так как последние лет десять я сидел под ubuntu то меня заинтересовало, а как там дела с шифрованием обстоят в linux.
Сразу оговорюсь. В первую очередь меня интересовала защита от случайных людей - сотрудников сервисных центров и мастерских, мамкиных хакеров и различных домашних аникейщиков. У меня нет задачи противостоять сотрудникам спецслужб, международным криминальным организациям и специалистам по криптографии. До этого, два раза, у меня был лайтовый опыт общения со следователями по уголовным делам и по этому, на свой счет, я иллюзий не испытываю.
У меня установлена ubuntu 22.04 и все манипуляции я проводил на ней. Но я думаю, что эта инструкция подойдет и к любым другим дистрибутивам. Каких то специфических, дистрибутив зависимых вещей там нет.
Итак, начал разбираться. Основной способ шифрования который сейчас предлагает при установке ubuntu и другие, это шифрование всего диска с помощью LUKS + LVM. Мне он не подошел. Во первых я не хотел переустанавливать ОС и во вторых я не хотел целиком шифровать весь диск. Для меня это слишком избыточный метод, я хотел шифровать только свою домашнюю папку. Хотя я знаю, что сейчас это наиболее правильный метод для защиты данных.
Далее по популярности шло использование eCryptFS. Этот способ до 2018 года тоже предлагался в ubuntu при установке. Затем Canonical по различным причинам отказался от него. На данный момент проект то ли поддерживается, то ли не поддерживается. До конца я так и не понял.
Поэтому я решил использовать fscrypt. Нативный метод шифрования для ext4. Разрабатывается и поддерживается google, используется в chromeOS и Android для шифрования. Ну, что еще надо.
Поверхностное гугление выдало пару инструкций. Но судя по комментариям после одной из них компьютер уходил в цикличную перезагрузку, ну а вторая просто не работала. Пришлось идти на гитхаб проекта и читать документацию.
Итак, если вы хотите зашифровать свою домашнюю папку с помощью fscrypt на уже установленной операционке с файловой системой ext4:
Включаем флаг шифрования на вашем устройстве
tune2fs -O encrypt /dev/ваш дискУстанавливаем инструменты для управления fscrypt и PAM модуль
apt install fscrypt libpam-fscryptСоздаем нового пользователя (например user1) и включаем его в группу sudo. Так как мы далее будем проводить манипуляции с нашей домашней папкой, то делать это лучше всего из под другого пользователя. Завершаем сеанс нашего основного пользователя (например user0) и заходим нашим новым пользователем (user1). Дальше все действия выполняем под ним.
Настраиваем fscrypt
user1@laptop:# sudo fscrypt setupбудет создан конфигурационный файл
Created global config file at "/etc/fscrypt.conf".и файл метаданных
Metadata directories created at "/.fscrypt"на запрос создания файла метаданных в корне ./ нажимаем Y
5. Создаем новую домашнюю папку user0-new
user1@laptop:# sudo mkdir /home/user0-newВключаем шифрование этой папки
user1@laptop:# sudo fscrypt encrypt /home/user0-new --user=user0(ваш основной пользователь)В появившемся диалоге выбираем 1. Т.е для дешифровки папки будет использоваться ваш пароль для логина в системе. И вводим пароль вашего основного пользователя(user0)
The following protector sources are available:
1 - Your login passphrase (pam_passphrase)
2 - A custom passphrase (custom_passphrase)
3 - A raw 256-bit key (raw_key)
Enter the source number for the new protector [2 - custom_passphrase]: 1
IMPORTANT: Before continuing, ensure you have properly set up your system for
login protectors. See
https://github.com/google/fscrypt#setting-up-for-login-protectors
Enter login passphrase for user0:
"user0-new" is now encrypted, unlocked, and ready for use.
Все папка создана и зашифрована. Теперь копируем в нее все данные из старой домашней папки
user1@laptop:#sudo cp -a -T /home/user0 /home/user0-new
Переименовываем старую домашнюю папку
user1@laptop:# sudo mv user0 user0.backup
Переименовываем новую шифрованную домашнюю папку
user1@laptop:# sudo mv user0-new user0
Все готово. Перезагружаемся и заходим вашим основным пользователем (user0). Если все нормально, то удаляем нового пользователя и папку с бекапом (user0.backup).
Комментарии (30)
unwrecker
00.00.0000 00:00Пользовался и ecruptfs, и encfs, перешел потом на LUKS отдельного раздела с точечным монтированием в разные места. Но предложенный вариант c fscrypt пожалуй интересней будет. Спасибо!
pae174
00.00.0000 00:00+8Шифрование только домашней папки это только видимость безопасности т.к. некоторые критические куски данных могут находиться за её пределами - разные настройки чего-либо системного, /tmp с каким-то странными штуками внутри, своп и так далее. Гораздо более безопасно в этом плане шифрование всего дискового раздела целиком.
TIEugene
00.00.0000 00:00-1во вторых я не хотел целиком шифровать весь диск
powerman
00.00.0000 00:00+4Ну, говоришь одно, а подразумеваешь другое. Не факт, что именно "не хотел".
Не могу знать наверняка, что было в голове автора, но предполагаю, что реальная мотивация далека от "не хотел". Возможно он всё-таки не хотел переустанавливать систему ради простого включения шифрования всего диска одной галочкой при установке убунты, а можно ли включить конкретно этот тип шифрования на уже установленной системе поленился разбираться. Плюс, как кажется на первый взгляд, все стоящие шифрования данные лежат в домашнем каталоге (нет, конечно). Плюс в шифрование одного каталога можно относительно безопасно "поиграться", а шифрование всего системного раздела - это вряд ли операция из серии "ошибся - ничего не испортил, не понравилось - легко отменил", поэтому эксперименты без острой необходимости ставить тупо стрёмно.
Тем не менее, вопрос включения шифрования на уже установленной системе для всего винта - актуален и интересен. Напр. в облаке запуская сервер ты получаешь ту же убунту уже установленной, причём - без шифрования. И задумываешься об этом недостатке когда на сервере уже много чего установлено и он активно используется… Так что если вдруг кто хочет написать аналогичную статью, только про шифрование всего винта - это было бы полезно. :)
MountainGoat
00.00.0000 00:00Swap действительно может слить чувствительные данные, но swap часто вообще отключают, или он без проблем шифруется сессионным ключом. /tmp нынче почти везде смонтирован в память и на диск не попадает никогда. А где ещё на обычном десктопе могут оказаться важные данные, я как-то придумать не могу. Список установленных пакетов и время последнего включения я секретными данными не считаю: те, кому надо прятать даже такое, на ноуте с собой такую систему не носят.
powerman
00.00.0000 00:00+1docker volumes? всякие snap/flatpak хз где что держат, не факт, что в домашнем каталоге всё. Ну и плюс лично я терпеть не могу, когда /tmp автоматом удаляется при перезагрузках - и я такой не один. Плюс нередко докупаются дополнительные винты т.к. места не хватает. Это сходу пока речь о рабочей станции. А когда речь заходит о сервере, то там любой системный сервис может иметь (или сам быть) БД с критичными данными.
Но суть не в конкретных кейсах и их распространённости, а в том, что когда речь заходит о безопасности всегда предпочтительнее в принципе не задумываться о том, что нужно шифровать, а что можно вроде бы я почти в этом уверен и не шифровать наверное но не факт.
skymal4ik
00.00.0000 00:00+1Ну и плюс лично я терпеть не могу, когда /tmp автоматом удаляется при перезагрузках - и я такой не один.
Используйте /var/tmp - он не очищается при перезагрузке
powerman
00.00.0000 00:00+1Вы не математик случаем? А то Ваш ответ… он… абсолютно верный, и абсолютно бесполезный - в контексте данной беседы. :) Я к тому, что
/var/tmpровно так же будет не зашифрован, и утечки будут через него.
Stanislavvv
00.00.0000 00:00man namespace.conf; man pam_namespace
Для перенаправления /tmp в ~/tmp/$user обычно достаточно.
powerman
00.00.0000 00:00+2А, и забыл самый смешной кейс: когда системный раздел не зашифрован, то всегда есть возможность туда подложить кейлоггер, который поможет выяснить пароль от зашифрованной части когда наивный юзер загрузится с этого системного раздела.
MountainGoat
00.00.0000 00:00+2И для всего этого нужно ноутбук незаметно украсть, поковыряться в нём и так же незаметно вернуть, чтобы владелец не узнал. А если ноут не в сети, то потом ещё раз украсть. Если есть возможность это провернуть, то есть и возможность встроить малварь в GRUB. Тогда уж нужно ещё и закрывать настройки UEFI, включать Trusted Boot, генерировать свой сертификат, регистрировать его в UEFI, подписывать им GRUB, ядро и все дополнительные дрова вроде Nvidia - а про всё это речи ни разу не было. Правда, теперь можно просто сбросить память на материнке, раз устройство в руках злоумышленника. Далеко не факт, что пользователь заметит, что ему сбросили системные настройки и переустановили GRUB. Значит нужно ещё подпаяться программатором к мультиконтроллеру и перенастроить его так, чтобы он сдох, если чексуммы не сойдутся. Правда, мультиконтроллер можно перепаять. Всё, фантазия кончилась.
Как видите, от варианта когда ноутбук физически побывал в руках злоумышленника и был незаметно возвращён, нельзя защититься внутри самого ноутбука. Поэтому я такой вариант и не рассматриваю.powerman
00.00.0000 00:00И для всего этого нужно ноутбук незаметно украсть, поковыряться в нём и так же незаметно вернуть, чтобы владелец не узнал.
Вопрос шифрования винта в принципе актуален только когда уже есть возможность доступа к выключенному компу. Поэтому вопрос с "незаметно украсть" мы не рассматриваем - данное условие уже выполнено. И не обязательно именно украсть, вполне можно добраться до чужого устройства когда владелец отвлёкся/отошёл, (пере)загрузить его со своей флешки (которая автоматически добавить тот же кейлоггер на системный раздел). Факт перезагрузки владелец, конечно, может заметить - если комп вообще был изначально включен, - но скорее всего спишет на глюк, а даже если и заподозрит что-то, то почти гарантированно это не остановит его от ввода пароля от зашифрованного каталога.
А если ноут не в сети, то потом ещё раз украсть.
Это тоже не проблема: во-первых редкое устройство не в сети, и во-вторых раз удалось получить физический доступ один раз - получить второй раз скорее всего тоже получится.
Если есть возможность это провернуть, то есть и возможность встроить малварь в GRUB.
Возможно так и есть. Но технически это явно будет сложнее.
Тогда уж нужно ещё и закрывать настройки UEFI, включать Trusted Boot,
генерировать свой сертификат, регистрировать его в UEFI, подписывать им GRUB, ядро и все дополнительные дрова вроде Nvidia - а про всё это речи ни разу не было.В тот момент, когда мы начинаем беспокоиться о шифровании винта - да, обеспечить защиту на уровне "до загрузки системы" скорее всего тоже нужно. Но тут я не до конца уверен - зависит от того, есть ли возможность встроить код для перехвата пароля от зашифрованного раздела на этом уровне и насколько это сложно/заметно.
Значит нужно ещё подпаяться программатором к мультиконтроллеру
Мне сложно оценить корректность/осмысленность данной идеи. Но такая атака определённо намного сложнее в реализации - как в плане требуемой квалификации исполнителя так и в плане незаметности её проведения и количества требуемого на неё времени. Грубо говоря когда владелец ноута сидя в кафе отошёл в туалет оставив ноут лежать на столе - что-то в нём перепаять вряд ли получится до возвращения владельца. Но на случай если в нашей оценке рисков такой риск необходимо учитывать некоторые материнки умеют определять факт вскрытия корпуса и сигналить об этом (впрочем, если мы уже дошли до паяльника, то наверное можно этот датчик тоже отключить, да и всю материнку тогда уже заменить целиком можно).
Как видите, от варианта когда ноутбук физически побывал в руках злоумышленника и был незаметно возвращён, нельзя защититься внутри самого ноутбука. Поэтому я такой вариант и не рассматриваю.
Защититься на 100% невозможно ни от чего, в принципе. Защита - это всегда вопрос соотношения меча (усилий на атаку) и щита (усилий на защиту). Но и ставить ворота посреди поля тоже нет никакого смысла - защита должна быть не "для галочки", а такая, которая увеличивает затраты усилий на взлом до той границы, которая считается приемлемой по нашей оценке рисков для тех угроз, от которых мы считаем необходимым защищаться.
Шифрование диска по определению подразумевает, что от риска получения физического доступа мы считаем необходимым защититься. Нужно ли при этом защищаться от риска незаметного получения физического доступа - вопрос, безусловно, отдельный - это другой риск который надо оценивать отдельно. Но часто ответ на него "да" просто потому, что если тот же вор имеет возможность украсть устройство, то это автоматически означает, что он имеет возможность сунуть в него флешку и перегрузить устройство вместо того, чтобы красть его. Поэтому я такой вариант рассматриваю. :)
MountainGoat
00.00.0000 00:00есть ли возможность встроить код для перехвата пароля от зашифрованного раздела на этом уровне
Модифицированный GRUB подкинет злостный драйвер прямо в ядро, если нет SecureBoot.
Допустим, юзер убежал в сортир. Что может случится.
Вариант 1: Убежал и не залочил комп. Юзер баран, никакое шифрование тут не поможет.
Вариант 1.1: Юзер залочил комп, но у него работает автозапуск с флешек. Системный администратор у юзера - баран. Никакое шифрование тут не поможет. Кстати, на Астра Линуксе пока экран залочен, похоже, udev встаёт на паузу - он вообще не распознаёт изменения в USB устройствах пока залочен. Не знаю, как с этим на нормальных линуксах.
вариант 1.2: Юзер залочил комп, но в блокировщике опять 0-day дырка. Шифрование опять не поможет никакое.
Вариант 2: Придётся перезагружать, но у юзера не стоит SecureBoot или пароль на настройки - подкидываем свою флешку с модифицированным GRUB, он заменяет собой системный, и при загрузке подкидывает кейлоггер в ядро либо записывает пароль при полнодисковом шифровании. Приходит юзер, вводит пароль, шифрование снова в пролёте.
Вариант 3: У юзера SecureBoot и пароль на GRUB и настройки. Без паяльника уже вообще никак.Есть ещё вариации, связанные с гипотетическими уязвимостями. Но тема во всех одна: я не смог придумать сценарий, в котором полнодисковое шифрование защищает содержимое хомяка лучше, чем шифрование хомяка и свопа. Кроме сценария когда злоумышленник может разобрать систему, вставить диск в свою систему, изменить его, вставить диск обратно, и юзер ничего не заметит.
powerman
00.00.0000 00:00По вариантам 1 и 1.1 полностью согласен.
Вариант 1.2 - честно говоря проще 0-day использовать через браузер подкинув юзеру ссылку, чем через блокировщик. Я бы вопросы 0-day в контексте шифрования диска вообще не рассматривал.
SecureBoot для линуха организовать не так просто, к сожалению.
А вот пароль на Grub и настройки UEFI поставить легко, равно как и заблокировать в UEFI загрузку с посторонних устройств. И это необходимо сделать как только доходит до шифрования диска - всего или части, не важно.
Можно ли исключать риск изменения диска через подключение его к чужой системе - зависит от того, как вероятность такого риска оценивает конкретный пользователь. Лично я бы такое не исключал - да, за время "вышел в туалет" такое провернуть сложно, но есть много других ситуаций, когда рядом с компом кто-то чужой может находиться длительное время (начиная от "ночью в офисе" и заканчивая "комп временно изымали на экспертизу менты"). В случае с кафе и туалетом это проворачивается в стиле "ноут украли!… (через полчаса) о, смотрите, мы нашли Ваш ноут - столик был пуст, официантка решила что ноут забыли, и отнесла в подсобку, чтобы вернуть когда владелец за ним вернётся".
strvv
00.00.0000 00:00Своп и tmp можно и нужно, т.к. повсеместно используется ssd, вынести в рамдиск, например используя zram. Памяти сейчас много, работать будет быстрее.
Для критичных сервисов и flatpack-ов - данные части ПО загружаются после инициализации фс и их можно аналогично папке зашифровать. И этот метод, шифрации необходимых мест с различными ключами устойчивее единого шифрования, т.к. при общем шифровании будет много иметься данных шифрованных и открытых,т.е. можно распараллеливание поиска ключей с высокой надёжностью.
13werwolf13
00.00.0000 00:00+1своп в рам? ну да, это всего лишь сломает гибернацию..
strvv
00.00.0000 00:00Я не пользовался гибернацией, ещё с стародавние времён, т.к. что-нибудь да перекосит, поэтому и её не учитываю. Если нужна - шифрование в свопе включается.
aik
00.00.0000 00:00некоторые критические куски данных могут находиться за её пределами
Это уже юзеру решать, что у него критично и ради чего он шифрование затеял.
KillJ0y
00.00.0000 00:00+1Если посмотреть в целом то не luks то не fscrypt не безопасный вариант, надежнее всего это правдопадобное отрицание, и доступно оно только через создание скрытой системы. Читаем veracrypt шифрование системы со скрытой системой. Если уж так вышло можете сообщить пароль от основной системы а там собственно нету ни чего( какие нибудь котики безобидные фотки свежая история браузера ) а для скрытой системы например использовать уже дополнительные методы безопасности USB токены, pim и и т.д
forthgate
00.00.0000 00:00Т.е для дешифровки папки будет использоваться ваш пароль для логина в системе.
Но это же никак не защитит данные, в чем проблема условному специалисту в сервис центре при включении компа подправить конфиг в бутлоадере, запустить сессию под рутом и выставить нужный пароль для учетки?
MartyBug Автор
00.00.0000 00:00Не знаю. Этот вариант если честно, я не продумывал. Надо будет завтра проверить этот вариант.
PS. Можно активировать пользователя root и задать ему пароль?
forthgate
00.00.0000 00:00Конечно, достаточно во время запуска бутлоадера отредактировать строку загрузки ядра в rw режиме, после этого можно сменить пароль у любой учетки
Вообще если уж вы хотели пользоваться этой тулзой, то наверное было бы надежнее шифровать кастомной фразой, а лучше ключом - 2 или 3 пункт
pae174
00.00.0000 00:00в чем проблема условному специалисту в сервис центре при включении компа подправить конфиг в бутлоадере, запустить сессию под рутом и выставить нужный пароль для учетки?
Рискну предположить, что для шифрования папки используется не хэш юзерского пароля а некий уникальный ключ, который хранится на диске в зашифрованном виде, и вот для его шифрования уже используется хэш пароля. В случае легитимной смены пароля происходит расшифровка ключа хэшем старого пароля и шифрование хэшем нового пароля. В случае простого сброса "пароля под рутом" ключ уже не расшифруется.
Так, или примерно так, работает шифрование папок в Windows и шифрование контейнеров в VeraCrypt (который бывший TrueCrypt).
sim2q
00.00.0000 00:00По этой статье как-то делал : Шифрование в EXT4. How It Works?
ps Все прекрасно работает, но в какой то момент одна директория была утеряна.
Сколько не подбирал пароль - мимо. Не понятно - скорее всего забыл или ошибся.Ещё там усугубилось переносом диска на другую машину. И есть некая вероятность, что система на которой шифровалось была с 32 битным ядром, а потом перехало на 64.
AlexVWill
00.00.0000 00:00А что не так с eCryptfs? По моему очень удобный инструмент для создания шифрованных разделов из папок, и поддерживается на уровне ядра, давно им пользуюсь для шифрования приватного раздела куда кидаю личные данные и кэш браузера. Вот инструкция есть, понятная и проверенная, работает все на ура, без глюков вообще... https://wiki.archlinux.org/title/ECryptfs_(Русский)
powerman
00.00.0000 00:00+1Ответ на этот вопрос от разработчиков fscrypt есть в самом начале их README: https://github.com/google/fscrypt#alternatives-to-consider
Belibak
Для luks не нужно ничего переустанавливать, и lvm не обязателен.