Configuring Linux
Information Security
*nix
Server Administration
Data storage
Comments 29
+2
TPM 2.0 только сейчас начинает появляться в железе, зачастую вместе с обновлениями BIOS.
Да уже скоро 4 года, как оно есть у Intel (начиная с H110), а у AMD, если не изменяет память, начиная с Ryzen.

И это лучше, чем ничего, поскольку колодка для подключения внешнего TPM даже на дешевых платах с топовым Z-чипсетом (например, ASUS Z170-P) в целях экономии не распаиваивается (хоть посалочное место есть, и то хорошо), а на самых бюджетных платах и того нет.

Secure Boot с установленными сертификатами Microsoft эквивалентен его отсутствию
А как вы без сертификата Microsoft решаете проблему с запуском GOP-драйверов внешних видеокарт, PXE-драйверов внешних сетевых карточек, NVME-накопителей? Если с видеокартами ещё можно слить из них прошивку и подписать с помощью какого-нибудь GOPUpdater, то о существовании инструментов для NVME-дисков мне неизвестно.
0
Мне на ASUS B150M-C и на Dell Inspiron 3552 пришёл TPM 2.0 только с обновлением BIOS где-то в конце прошлого года. До этого TPM 1.2 просто никак не получалось завести на линуксе.
0
Как раз в конце 2018 для этой платы вышла новая мажорная версия прошивки (3xxx -> 4xxx). Интересно, с чем связано отсутствие до этого. На моей Z170-P поддержка PTT присутствует, как минимум, с 2016 года (более ранние прошивки я просто не проверял).
0
С secure boot ещё не все опции ядра работают. Например на некоторых моделях Lenovo невозможно включить турборежим процессора из-за неверных таблиц acpi.

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

Ну а если Linux убил прошивку (как уже бывало из-за рукожопости инженеров Lenovo), то уже всё равно, какие там были ключи, и такое убиение может случится вообще независимо от состояния Secure Boot.
0
Кстати, все рецепты, которые я привёл в статье (ссылка на рецепт для федоры и мой репозиторий) предусматривают резервное копирование ключей первым делом.
+2

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

0
Да, всё верно, если известно, что техника скомпрометирована — остаётся только зачистить под ноль. Если полагаться только на это, то нужно заменять компьютер после похода на обед/в туалет более чем на полчаса; после сдачи в багаж в аэропорту; после потери питания в датацентре, если это сервер; после сдачи в сервис и так далее.
+6

Я проще сделал, у меня загрузчик с luks header'ом на флэшке. Но full chain, конечно, лучше.

+1
Я конечно не спец в шифрованиях, но выходит без этих танцев с security boot и загрузчиками, весь этот LUKS безтолку? Реально все так просто разшифровывается.
0
Если технику просто украдут, то шифрование поможет. Если незаметно такое провернут и владелец воспользуется компьютером — да, проблема. Secure Boot настроить не так трудно — пару раз в BIOS зайти и несколько команд прогнать.
Тут по сути ситуация похожа на фишинг паролей через сайты-подделки. Только по адресу сайта-подделки обычно видно, что это не тот сайт, а тут нет.
0
Так ещё надо настроить переподписывание ядра и initrd при обновлении, как-то организовать offline хранение корневого сертификата. И при любой ошибке иметь риск остаться без компьютера.
0
Решение в статье предусматривает переподписывание. Сертификат не представляет из себя особой ценности — при необходимости заходите в BIOS, вводите пароль администратора и сбрасываете платформу в режим установки. В статье этот момент оговорен.
0
Если вы неуловимый Джо (в 99.99% так и есть) LUKS спасёт от очень любопытных глаз тех, кто может получить получить доступ к вашему компу/жесткому диску. Если кто-то собирается провести против вас операцию по подмене загрузочных файлов, то у вас уже неприятности.
+2
без этих танцев с security boot и загрузчиками, весь этот LUKS безтолку?

Каждый из этих «танцев» защищает от своего сценария атаки.

1) Шифрование данных защищает от «воткнули любой LiveCD/воткнули диск в другой ПК, наплевали на автори��ацию в системе и полезли смотреть содержимое диска». Это самое актуальное для большинства пользователей, поскольку накопитель можно потерять (вместе с ноутбуком), либо туда могут попытаться сунуть нос любопытные враги в погонах.

2) SecureBoot защищает от «в отсутствие владельца подменили его загрузчик GRUB на собранный злоумышленником кастомный GRUB, который логгирует введённый пароль и куда-то его сохраняет, чтобы потом можно было его заполучить» (атака EvilMaid). Если против вас такое организовали, то вы уже явно не рядовой пользователь.

3) Пароль на вход в настройки BIOS защищает от «зашли в биос, отключили SecureBoot и провернули п.2».

4) Использование TPM при шифровании защищает от «вытащили батарейку, сбросили пароль на биос, провернули п.3 и п.2» и от «прошили изменённую прошивку со встроенным UEFI-руткитом».

Безопасность — это комплекс мер. Например, использование лишь SecureBoot с собственными ключами защитит от подмены аагрузчика, но не защитит от банального «втыкаем диск в другую машину и смотрим содержимое».

Плюс ещё и разработчики операционных систем должны не зевать. Например, шины Thunderbolt и FireWire позволяют получить прямой доступ к оперативной памяти (откуда можно выудить ключ шифрования системного накопителя). Поэтому, разумно сделать так, чтобы устройства, вставленные при заблокированном сеансе (когда пользователь отошёл), не подключались. В Windows 10, например, это реализовано с помощью групповых политик, начиная с 1607 (а в 1803 добавили автоматически включаемую Kernel DMA Protection for Thunderbolt 3, правда, только при использовании процессоров Intel).
0
Почему вы выбрали путь с отдельным загрузчиком, initramfs и т.д., а не шифрование /boot и установку подписанного загрузчика?
+1
Главная причина — это было бы полумерой. Шифрование LUKS1 (LUKS2 c integrity GRUB не поддерживает) не гарантирует целостность данных. Действительно, подмену сформировать трудно, но не невозможно: см. слабые стороны XTS. Вместо этого я предпочёл иметь криптографические гарантии, что ядро подписано, конфиг GRUB подписан, инитрамдрайв подписан. О сомнительной пользе шифрования /boot я упоминал в статье.

В дополнение к этому такая схема легка во внедрении и сохраняет возможность воспользоваться оригинальным загрузчиком, отключив Secure Boot. То есть пользователь такого рецепта особо ничем не рискует, развёртывая это у себя на копьютере.
0
Ссылку на запрос на поддержку LUKS2 для GRUB оставлю здесь: savannah.gnu.org/bugs/?55093.
В случае btrfs подмена легко выявляется ввиду сохранения контрольных сумм файлов в ФС.
0

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

0
При каждом монтировании проверяться все файлы не могут. Насколько мне известно, btrfs проверяет данные при их чтении. Для проверки всего диска можно использовать btrfs scrub start.
0
Ноутбуки как правило подключаются к сети Интернет через WiFi и соотвественно в момент загрузки ноутбука после ввода пароля к сети с помощью вашего скрипта ноутбук подключиться не сможет, если только не подключится к какой-либо открытой точки доступа без пароля(которых сейчас практически нет, используется авторизация через смс), а уже после загрузки самой системы ваши скрипты не будут работать. Получается, что ноутбуки уязвимы только если подключены к ethernet?
0
Нет, можно дождаться появления интернета для отправки пароля, спрятать ключ где-то на диске, добавить свой пароль на диск в кейслот LUKS, всё что угодно. Скрипты в моей демонстрации написаны для образовательных целей, а не для нужд практикующих злоумышленников.
0
Не пользовался им, но принципиальных отличий тут нет. Проблема не в самом способе шифрования, а в том, что можно вмешаться в работу компьютера до разблокировки и направить дальше действия компьютера в нужное для извлечения данных русло.
0
Получается из коробки даже упомянутые в статье Fedora и OpenSuSE не дают достаточной защиты при включенном Secure Boot? Так же любой вариант может быть скомпрометиррован при отсутствии пароля на bios?
0
А насколько пароль на биос надежная штука? То есть разве он не сбрасывается елси там батарейку вытащить? Или чето подпаять. Просто не сильно шарю в этом.
0
Ненадёжная, но придётся корпус точно вскрывать. Ну и если видно, что корпус вскрывался и Secure Boot сброшен, то как бы всё понятно.

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

  • Встроить аппаратный кейлоггер между клавиатурой и устройством, позже забрать его или ��олучить беспроводным методом. Это никак не определить без дополнительных мер защиты конкретно против такого способа получения пароля.
  • Полностью подменить биос/чипсет и накопитель, чтобы процесс загрузки визуально соответствовал привычному. После ввода пароля не важно, что система не загрузится, пароль-то уже будет отправлен по сети. Даже если на биосе при включении стоит пароль, можно сделать так, чтобы он принимал любой пароль, всё равно никто не вводит сначала неправильный, чтобы убедиться в корректности алгоритмов.

Only those users with full accounts are able to leave comments., please.