в этом вопросе я только понял, что вы зачем-то установили себе Devuan и теперь хотите, чтобы вас убедили, что это имело какой-то смысл. Подождите, пока не вознет очередная тема по выражению ненависти к systemd, в ней вас будут в этом убеждать.
Devuan - очень одобряю выбор, потому как он даже бинарно почти совпадает с Debian, а Debian без systemD был просто шикарен.
Обязательно Libreboot с GRUB2, прошитым тоже в чип бивиса материнки, далее загрузка всего с полностью зашифрованных дисков, которые открываются с помощью Nitrokey Pro2 или Rutoken ECP2.
Изоляцию процессов нужно делать с помощью отдельных физических компов, а не через KVM/QEMU и уж тем более не через chroot или контейнеры.
Конечно же обязательны бэкапы с паролем 123 без всяких ключей, ибо пропавший ключ не должен стать причиной вашей личной трагедии.
Наличие LiveCD, с которого нужно иметь возможно протестить чексуммы вашей установки аналогично утилите: wajig integrity
Возможно, кто-то умеет и изящнее, но хотя бы и так сойдет на первое время.
Ну и таки Gentoo или GUIX почему-то выглядят благонадежнее Debian based на предмет софтовых закладок даже в правильных deb пакетиках.
можешь написать скрипт прохода по списку пакетов и проверить отличия.
а мож где уже готовый есть.
wajig integrity
Только от него немного толку, если скомпроментированны бинарники, ответственные за проверку.
С моей точки зрения надо обновиться до последних версий, скопировать список установленных пакетиков и потом сделать debootstrap с этим списком в ранее пустой каталог с LiveCD.
И потом сравнить rsync --dry-run, хоть какая-то проверка.
BuildID is NOT the hash of a binary or related to it. It is an identifier for the «build» (or compiling) session which produced that binary. It is mostly there for debug purposes, so that the developers can look at the logs, environment, etc. from session number $BuildID and try to fix the problem, reproduce it, etc.
Только от него немного толку, если скомпроментированны бинарники, ответственные за проверку.
если скомпрометированы бинарники, то теоретически может быть что угодно.
но качественно скомпрометировать бинарь хеш-подписи для правильного ответа с заранее неизвестным ответом (хеш-база над ругой машине)
все зависит от выбранного уровня сложности задачи.
мудрить с debootstrap имхо крайне излишнее. небольшой образ системы, разворачиваемой в рам и имеющей минимальный набор для конкретной проверки будет и проще и эффективнее.
rsync –dry-run тоже как-то излишне. полноценную копию корня еще где-то надо держать и иметь к ней доступ, и периодически отливать изменения, ибо в ином случае не поймешь: файлик изменен обновлением, юзером или злодеем.
md5sum имхо хватит за глаза.
Я в курсе под IMA/EVM, но оно по умолчанию не включено ни в одном дистрибутиве. Аналогично с доверенной загрузкой.
Секретный ключ для dm-verity в Android находится в initrd, если не ошибаюсь, который вшит в ядро.
Я в курсе под IMA/EVM, но оно по умолчанию не включено ни в одном дистрибутиве.
GRUB с поддержкой RSA и ядро Линукс с IMA/EVM по умолчанию есть во всех дистрибутивах, если они УМЫШЛЕННО его не отключили.
Есть проблема с инсталлером, где будет для хомячков стоять галочка «включить верификацию системы при загрузки». И проблема с написанием корректной программы обновления системы с верификацией загрузки. Также стоит проблема как быть с suspend to swap и гарантией верификации системы восстановленной со спящего режима. Все проблемы решаемы, но в популярных дистрах этим занимался не хотят, они заняты сЫстемдЫ и ускорением загрузки и пробуждения системы, а верификация установку/загрузку/обновления чуть притормозит.
Пользователи верификацию делают сами. Предварительно поплачут от руткитов троянов майлвари и потом сделают.
Аналогично с доверенной загрузкой.
Это уже сильно зависит от купленной материнской платы. Для плат с поддержкой Coreboot можно организовать полную доверительную загрузку.
Секретный ключ для dm-verity в Android находится в initrd, если не ошибаюсь, который вшит в ядро.
Ошибаешься! В ядре есть только ПУБЛИЧНЫЙ ключ для верификации подписей. Подписать публичным ключом ничего невозможно.
А секретный ключ, необходимый для подписи, есть у Google и копия у майора с АНБ. ;)
Загрузка чего-то там подлинного еще ничего не значит, если в исходниках или бинарниках были подмены. Подлинность начинается c git signed commits, публичных хэшей и контрольных сумм. В простейшем случае это iso-образ с публичным хэшами производителя. Как правило установленная ОС с такого образа и есть минимальная гарантия подлинности.
это всего лишь вариант проверки доступными средствами с минимальной заморочками.
никто не запрещает заиметь полную копию оф.репозитория и сгенерить из него полноценную базу устанавливаемых файлов с хешами/правами/версиями и всем прочим желаемым блекджеком.
а в системе лежит лишь небольшой скриптик который каждый имеющийся файл сравнивает с базой и выдает результат.
решение зависит от тз.