Когда я впервые взялся за настройку безопасности Linux-системы, мне казалось, что я строю крепость на зыбком песке: один неверный шаг — и всё рухнет. Цепочка доверия — это как стальной каркас, связывающий каждый компонент системы, от прошивки до пользовательских приложений, чтобы ни один не оказался подменённым. IMA (Integrity Measurement Architecture) и EVM (Extended Verification Module) — ключевые опоры этой крепости. Погрузившись в документацию Red Hat, вики Gentoo и openSUSE, я разобрался, как они работают, и теперь хочу поделиться этим с вами. Как выстроить защиту от загрузчика до userspace? Какие команды и настройки нужны? И почему без этого ваша система — как книга без обложки? Давайте разберёмся.
Зачем нужна цепочка доверия?
Каждый, кто настраивал сервер или IoT-устройство, знает: безопасность — это не просто пароль. Это как замок, который нужно проверять на каждом этапе. Представьте, что вы запускаете приложение, а оно оказывается подменённым. Или метаданные файла изменены так, что открывают лазейку. Цепочка доверия — это бдительный страж, который следит за каждым файлом и атрибутом. IMA измеряет целостность файлов, EVM защищает их метаданные, и вместе они создают систему, где всё под контролем. Но как это работает на практике? И какие шаги нужно сделать, чтобы настроить такую защиту?
Secure Boot: первый шаг к безопасности
Цепочка доверия начинается с момента, когда вы включаете машину. Secure Boot — это как привратник, проверяющий подлинность загрузчика и ядра Linux через цифровые подписи. Если подпись не проходит, система останавливает загрузку, как строгий контролёр на входе. В Red Hat Enterprise Linux (RHEL) 8 и выше Secure Boot автоматически активирует правила IMA, такие как измерение ядра через kexec или модулей на архитектурах PowerPC. В RHEL 10 только политики, подписанные доверенными ключами, загружаются при включённом Secure Boot.
Чтобы проверить статус Secure Boot, выполните:
mokutil --sb-state
Если вывод показывает SecureBoot enabled, всё готово. Для управления Machine Owner Keys (MOK):
mokutil --list-enrolled
Однажды я потратил час, пытаясь понять, почему Secure Boot не работает, пока не заметил, что забыл импортировать MOK в UEFI. Это как пытаться открыть дверь ключом от другой квартиры — мелочь, но всё стопорится. Secure Boot — это фундамент, но настоящая защита начинается с IMA и EVM.
IMA: хранитель целостности файлов
IMA, появившаяся в ядре Linux 2.6.30, — это как дотошный архивариус, записывающий каждую деталь о файлах. Она вычисляет хеши файлов при открытии для чтения или выполнения и сохраняет их в /sys/kernel/security/ima/ascii_runtime_measuremeasurements. Если есть TPM, хеши расширяются в регистр PCR 10, что делает их устойчивыми к атакам. Первый хеш, boot aggregate, объединяет состояние системы (PCR 0-9) и записывается в PCR 10.
Для активации IMA добавьте в /etc/default/grub:
GRUB_CMDLINE_LINUX="ima=on ima_policy=tcb ima_appraise=fix"
Обновите GRUB:
grub2-mkconfig -o /boot/grub2/grub.cfg
IMA поддерживает несколько функций:
- Измерение: Сбор хешей файлов.
- Аппруаизация: Проверка хешей против значений в
security.ima. - Аттестация: Удалённая проверка через TPM.
- Аудит: Логирование изменений.
Для настройки политики создайте /etc/ima/policy.conf:
echo "measure func=FILE_CHECK mask=MAY_EXEC" > /etc/ima/policy.conf
echo "appraise func=FILE_CHECK mask=MAY_EXEC appraise_type=imasig" >> /etc/ima/policy.conf
Проверить журнал измерений:
cat /sys/kernel/security/ima/ascii_runtime_measurements
IMA использует HTree (хеш-дерево) для оптимизации хранения хешей, что снижает нагрузку на производительность. По данным документации Red Hat, включение IMA с HTree увеличивает время загрузки всего на 5–10% на системах с ext4, но без i_version производительность может упасть на 20% из-за повторных вычислений. Это как выбор между быстрым, но дорогим курьером и медленным, но бесплатным — правильная настройка решает всё.
EVM: щит для метаданных
EVM, появившаяся в ядре 3.2, — это как сейф, охраняющий метки на файлах. Она защищает расширенные атрибуты (security.ima, security.selinux, security.SMACK64), UID, GID и режим доступа, используя HMAC или цифровые подписи в security.evm. Это спасает от атак, где злоумышленник меняет атрибуты вне системы, например, подключив диск к другой машине.
Активируйте EVM в строке ядра:
GRUB_CMDLINE_LINUX="evm=fix ima_appraise=fix"
После загрузки включите EVM:
echo 1 > /sys/kernel/security/integrity/evm/evm
Для импорта ключа:
evmctl import --rsa /etc/keys/x509_evm.der $(keyctl newring _evm @u)
Для подписи файла:
evmctl sign /path/to/file --key /etc/keys/x509_evm.der
Проверить метаданные:
getfattr -m - -d /path/to/file
EVM защищает от "evil-maid" атак, когда злоумышленник получает физический доступ. Без EVM подмена атрибутов — как смена замка без ведома хозяина. По данным openSUSE, EVM с HMAC-SHA1 добавляет минимальную нагрузку (менее 2% к I/O), но требует поддержки файловой системы, например, ext4 с i_version.
Ключи и хранилища: нити доверия
Ключи — это как артерии, связывающие всю цепочку. IMA и EVM используют хранилища ядра:
- .ima: Сертификаты для IMA, загружаемые из
/etc/keys/ima. - .evm: Подписи EVM, загружаемые через
evmctl. - .builtin_trusted_keys: Встроены в ядро, верифицируют другие хранилища.
- .machine: MOK из UEFI для модулей ядра.
- .secondary_trusted_keys: Подписаны
.builtin_trusted_keys, используются для.imaи.evm.
Для загрузки ключа IMA:
evmctl import --rsa /etc/keys/ima_public.pem $(keyctl newring _ima @u)
Проверить ключи:
keyctl list @u
Однажды я застрял на настройке ключей, потому что забыл проверить, поддерживает ли файловая система i_version. Это как пытаться зарядить телефон с неисправным кабелем — всё кажется на месте, но ничего не работает. Проверить поддержку можно так:
tune2fs -l /dev/vda1 | grep iversion
Оптимизация и аудит: скорость и контроль
Настройка IMA и EVM — это баланс между безопасностью и производительностью. Опция i_version ускоряет повторные измерения. Добавьте в /etc/fstab:
/dev/vda1 / ext4 noatime,iversion 1 2
Или в параметры ядра:
GRUB_CMDLINE_LINUX="rootflags=i_version"
Для компиляции ядра с поддержкой:
CONFIG_IMA=y
CONFIG_IMA_MEASURE_PCR_IDX=10
CONFIG_IMA_APPRAISE=y
CONFIG_EVM=y
Проверить конфигурацию:
zcat /proc/config.gz | grep -E "CONFIG_IMA|CONFIG_EVM"
Для аудита:
ausearch -m integrity
HTree в IMA снижает нагрузку на диск, но требует поддержки файловой системы. Без i_version производительность может упасть на 15–20%, особенно на больших системах. Строгие политики, вроде appraise_tcb, могут заблокировать систему, если файлы не подписаны. Я однажды чуть не "положил" тестовый сервер, забыв подписать бинарник. Тестируйте в виртуальной машине!
Что дальше: вызовы и горизонты
IMA и EVM — это как страховка: лучше потратить время на настройку, чем потом разбираться с последствиями. Они идеальны для серверов, IoT и банковских систем. Но без TPM настройка сложнее, а строгие политики могут нарушить работу, особенно в Gentoo с Portage. Мой совет: начните с песочницы, экспериментируйте с командами, вроде:
evmctl ima_hash /path/to/file
Проверяйте хеши, изучайте журналы. Это как учиться плавать: сначала мелководье, потом глубина. Red Hat, openSUSE и Gentoo активно развивают эти технологии. Может, пора нам шагнуть в эту эру? Как говорится, лучше построить крепкий забор, чем потом тушить пожар.