fs-verity и dm-verity в Linux: защита файлов и корневой системы от подмены

fs-verity и dm-verity: какой механизм решает вашу задачу

fs-verity защищает отдельные файлы на уровне файловой системы. dm-verity проверяет блоки неизменяемого блочного устройства, включая корневую систему. Выбор зависит от объекта защиты: файл или весь образ rootfs.

Оба механизма используют дерево Меркла и обнаруживают изменение данных при чтении. fs-verity подходит для выборочной защиты файлов, dm-verity - для целого read-only-образа. Verity обнаруживает подмену, но сам по себе не решает задачу доверия к root hash; для этого нужны защищенная загрузка, подпись метаданных или цепочка доверия.

Краткое сравнение fs-verity и dm-verity

Таблица ниже показывает ключевые различия по объекту защиты, уровню работы, режиму записи, способу проверки, реакции на ошибку, требованиям к образу, типовым сценариям и сложности обновления.

Что именно гарантирует verity, а что остается за пределами механизма

Verity обнаруживает изменение данных при чтении. Результат зависит от root hash: если он не защищен, злоумышленник может подменить и данные, и хеш. Механизм не защищает автоматически от компрометации загрузчика, ядра, initramfs, ключей подписи или управляющей системы обновлений.

Требования к ядру, файловой системе и userspace

Для fs-verity нужно ядро с CONFIG_FS_VERITY, файловая система ext4 или f2fs, утилиты fsverity-tools. Для dm-verity - CONFIG_DM_VERITY, cryptsetup или veritysetup. Проверьте версию ядра: uname -r. Проверьте конфигурацию: zgrep CONFIG_FS_VERITY /proc/config.gz или zgrep CONFIG_DM_VERITY /proc/config.gz. Установите пакеты: на Debian/Ubuntu apt install fsverity-utils cryptsetup-bin, на RHEL/CentOS dnf install fsverity-utils cryptsetup. Убедитесь, что systemd и initramfs поддерживают verity (обычно в современных дистрибутивах).

Как работает проверка целостности в fs-verity

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

Какие файлы имеет смысл защищать

Защищайте исполняемые файлы, плагины, политики, статические ресурсы, доверенные конфигурации и файлы моделей. fs-verity не заменяет права доступа, SELinux, AppArmor, антивирусную проверку или цифровую подпись.

Ограничения fs-verity для изменяемых данных

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

Пошаговая настройка fs-verity для отдельных файлов

Выполните команды в тестовой среде с правами root. Используйте отдельный тестовый файл.

Проверка файловой системы и установка инструментов

Проверьте тип файловой системы: findmnt -T /path/to/file или stat -f -c %T /path/to/file. Должна быть ext4 или f2fs. Установите fsverity-tools, как описано выше. Проверьте доступность команды: fsverity --version.

Создание и включение verity для файла

Выберите файл, например /usr/bin/myapp. Включите verity: fsverity enable /usr/bin/myapp. Если файл уже имеет verity, команда вернет ошибку. После включения файл становится read-only.

Получение digest и сохранение эталона

Получите digest: fsverity digest /usr/bin/myapp. Вывод в формате sha256:.... Сохраните digest в манифесте вместе с версией пакета. Рекомендуется подписывать манифест внешним ключом, если digest используется как корень доверия.

Проверка работы и тестирование подмены

Проверьте статус: fsverity status /usr/bin/myapp. Попробуйте прочитать файл: cat /usr/bin/myapp > /dev/null. Для теста подмены сделайте копию файла, измените содержимое, затем попытайтесь прочитать. Ожидайте ошибку чтения. Анализируйте dmesg и journalctl.

Интеграция fs-verity с приложением или системой доставки файлов

Схема: скачать артефакт, проверить подпись, установить файл, включить fs-verity, сверить digest, только затем запускать приложение. Проверяйте наличие verity перед запуском через systemd unit или deployment script.

dm-verity для read-only корневой системы Linux

dm-verity защищает весь образ rootfs на блочном уровне. Данные rootfs размещаются в неизменяемом образе, отдельная область содержит дерево хешей, device-mapper проверяет блоки при чтении, а root hash описывает ожидаемое содержимое всего устройства. Rootfs должен монтироваться только для чтения.

Когда dm-verity оправдан на сервере и в embedded Linux

Используйте dm-verity для appliance-систем, edge-узлов, kiosk, immutable OS, доверенных образов виртуальных машин и систем, где rootfs не должен изменяться во время работы. Для обычного изменяемого сервера dm-verity потребует вынести /var, /etc или другие изменяемые каталоги на отдельные разделы либо overlayfs.

Разделение read-only rootfs и изменяемых данных

Типовая схема: rootfs.img, отдельные /var, /home, /srv или persistent-разделы и временный tmpfs. Не оставляйте внутри защищенного образа каталоги, которые должны изменяться.

Особенности блока данных, блока хешей и root hash

Размер блока данных и хешей должен быть одинаковым. Важны выравнивание, фиксированный размер образа и неизменность файла после расчета root hash. Параметры сохраняйте вместе с образом и загрузочной конфигурацией.

Сборка и проверка образа dm-verity: пошаговый сценарий

Выполните на тестовой машине. Понадобятся root, loop device, mkfs.ext4, veritysetup.

Подготовка rootfs и фиксированного образа

Создайте каталог rootfs, наполните его файлами. Создайте образ: dd if=/dev/zero of=rootfs.img bs=1M count=512. Создайте файловую систему: mkfs.ext4 rootfs.img. Смонтируйте через loop: mount -o loop rootfs.img /mnt/rootfs. Скопируйте файлы: rsync -a /path/to/rootfs/ /mnt/rootfs/. Размонтируйте: umount /mnt/rootfs. Выполните sync. Зафиксируйте размер.

Создание verity-метаданных через veritysetup

Создайте файл для хешей: dd if=/dev/zero of=hash.img bs=1M count=64. Выполните: veritysetup format rootfs.img hash.img. Команда выведет root hash и параметры. Сохраните root hash в deployment manifest.

Подключение mapping и монтирование rootfs только для чтения

Создайте mapping: veritysetup open rootfs.img vroot hash.img <root_hash>. Проверьте: ls /dev/mapper/vroot, dmsetup status vroot. Смонтируйте: mount -o ro /dev/mapper/vroot /mnt/rootfs. Попытка записи должна завершиться ошибкой.

Проверка повреждения данных и hash tree

На копии образа измените блок данных или метаданных. Подключите mapping, попытайтесь прочитать. Ожидайте ошибку EIO. Анализируйте dmesg. Не повреждайте единственную рабочую копию.

Проверка параметров перед передачей образа в эксплуатацию

Сверьте размер устройства, block sizes, root hash, UUID или PARTUUID, расположение hash tree, права доступа, режим read-only и контрольную подпись манифеста.

Интеграция dm-verity с initramfs и загрузкой Linux

Загрузчик передает параметры, initramfs находит data и hash устройства, systemd-veritysetup или ручной скрипт создает mapping, затем ядро монтирует защищенный rootfs. Варианты различаются на базе systemd, dracut и initramfs-tools.

Какие параметры должен получить initramfs

Логическая конфигурация: идентификаторы data/hash-разделов, root hash, имя verity mapping, параметр root. Синтаксис зависит от версии systemd, dracut, initramfs-tools и загрузчика.

Пример загрузки через GRUB

В /etc/default/grub добавьте параметры ядра: rd.verity=1 roothash=<root_hash> systemd.verity=1. Обновите GRUB: update-grub. Обновите initramfs: update-initramfs -u. Перед переключением на verity оставьте рабочий вариант загрузки.

Пример интеграции с systemd-veritysetup

Создайте unit-файл systemd-veritysetup@vroot.service или используйте генератор. Укажите data device, hash device, root hash. Порядок раннего запуска и зависимость от доступности устройств.

Как доказать после загрузки, что rootfs защищен

Проверьте: findmnt /, lsblk -f, dmsetup ls, dmsetup status, cat /proc/cmdline, systemctl status systemd-veritysetup, journalctl -b. Ожидайте имя mapping и режим ro.

Типовые ошибки и диагностика verity

Диагностическая карта: симптом, вероятная причина, проверка, исправление.

Неверный root hash или измененный образ

Повторно получите root hash из того же набора data и hash устройств, сверьте manifest, убедитесь, что образ не был пересобран после расчета.

Несовпадение размера блока и размера устройства

Проверьте block size, размеры разделов, offset, количество блоков и выравнивание. Нельзя менять размер data device после создания hash tree.

Система пытается записать в защищенный rootfs

Проверьте mount options, расположение /var, /run, /tmp, /etc и каталогов приложений. Рассмотрите отдельные writable-разделы, tmpfs и overlayfs.

Нет поддержки fs-verity или dm-verity в ядре

Проверьте zgrep CONFIG_FS_VERITY /proc/config.gz или zgrep CONFIG_DM_VERITY /proc/config.gz, наличие модулей, сообщения modprobe, dmesg и journalctl.

Проблемы с initramfs, GRUB и идентификаторами устройств

Проверьте наличие утилит в initramfs, UUID/PARTUUID, порядок появления устройств, обновление initramfs и фактическую командную строку ядра.

Диагностика ошибок чтения после загрузки

Сопоставьте сообщения dm-verity в dmesg с I/O-ошибками, состоянием диска, dmsetup status и результатами чтения отдельных файлов. Verity не заменяет SMART, RAID и резервное копирование.

Безопасное обновление защищенного образа и план отката

Рекомендуется модель с неизменяемыми версиями образов и отдельными метаданными. Основной сценарий: A/B-слоты или сохранение предыдущего образа до подтверждения успешной загрузки.

Подготовка новой версии rootfs

Соберите новый образ в отдельном рабочем каталоге, установите пакеты и конфигурацию, выполните тесты, создайте hash tree, получите root hash и сформируйте manifest с версией, размерами, UUID и контрольными подписями.

Проверка образа до переключения загрузки

Подключите новый образ в тестовой виртуальной машине или через loop device, проверьте dm-verity, загрузку initramfs, systemd units, сетевой доступ, SSH, журналы и наличие всех writable-разделов.

Переключение на новый образ по схеме A/B

Запишите новый data device и hash tree в неактивный слот, опубликуйте root hash и параметры загрузки, установите одноразовую попытку загрузки и подтверждение успешного старта через boot counter или health-check.

Откат после неудачной загрузки или ошибки проверки

Предусмотрите автоматический возврат на предыдущий слот при тайм-ауте, kernel panic, невозможности смонтировать rootfs или провале health-check. Для ручного отката выберите старую запись в GRUB, восстановите предыдущий root hash и проверьте целостность старого образа.

Удаление старой версии и аудит обновления

Храните предыдущий образ до завершения окна наблюдения, затем удаляйте его только после резервного копирования и фиксации результата. Журналируйте root hash, версию, время переключения, результат проверки и оператора или pipeline.

Практический выбор и контрольный чек-лист

Что выбрать: fs-verity или dm-verity

Для отдельных файлов в обычной изменяемой системе используйте fs-verity. Для целого неизменяемого rootfs или appliance - dm-verity. Комбинация обоих механизмов оправдана для защищенного rootfs и дополнительной проверки отдельных артефактов.

Чек-лист перед внедрением

• Проверить поддержку ядра
• Проверить совместимость файловой системы
• Создать резервную копию
• Настроить раздельные writable-разделы
• Сохранить параметры verity
• Защитить root hash
• Проверить initramfs
• Обеспечить аварийный доступ
• Протестировать rollback

Минимальный набор команд для быстрой проверки

Команды для эксплуатации:

• uname -r - версия ядра
• zgrep CONFIG_FS_VERITY /proc/config.gz - поддержка fs-verity
• zgrep CONFIG_DM_VERITY /proc/config.gz - поддержка dm-verity
• fsverity digest /path/to/file - digest файла
• dmsetup status - состояние mapping
• cat /proc/cmdline - параметры загрузки
• mount | grep ' / ' - режим монтирования
• journalctl -b | grep verity - сообщения verity
• systemctl status systemd-veritysetup - статус сервиса

Дополнительные материалы по безопасности Linux и Docker: Скачайте готовые и проверенные шаблоны Dockerfile, проверка ISO-образов Windows, чек-лист безопасности Docker.