Почему SELinux и AppArmor не работают одновременно: технический анализ Linux Security Modules, эксклюзивных флагов и перспективы стекинга LSM в ядре

Введение: мечта о двойной защите

Когда я впервые начал настраивать серверы, мне казалось, что безопасность — это как надеть два бронежилета: чем больше слоёв, тем лучше. Почему бы не включить SELinux и AppArmor одновременно, чтобы создать непроницаемый барьер? Это как запереть дверь на два замка — надёжнее, правда? Но реальность ударила, как холодный душ: ядро Linux не позволяет этим двум титанам работать в паре. Почему? Этот вопрос, словно заноза, не давал мне покоя. За годы работы с Linux я разобрался в тонкостях Linux Security Modules (LSM), и теперь готов рассказать, почему SELinux и AppArmor конфликтуют, какие технические барьеры мешают их союзу и что ждёт нас в будущем с развитием стекинга LSM. Эта статья — глубокое погружение в ядро, с практическими примерами, командами и размышлениями, чтобы ты мог не только понять проблему, но и найти пути её решения.

LSM: невидимый страж ядра

Linux Security Modules (LSM) — это как фильтр, который проверяет каждое действие в системе: открытие файла, запуск процесса, подключение к сокету. Представь себе швейцара, который стоит у входа в ядро и решает, кого пустить. LSM предоставляет хуки — точки в коде ядра, где модули вроде SELinux, AppArmor или Smack могут вмешаться и вынести вердикт. Когда я впервые столкнулся с LSM, мне казалось, что это универсальный ключ к любой защите. Но, честно говоря, он больше похож на узкий мост, где два путника не могут разойтись.

LSM был создан, чтобы упорядочить хаос, когда каждый модуль безопасности пытался напрямую встраиваться в ядро. Хуки стали единым интерфейсом, но с подвохом: они не рассчитаны на одновременную работу двух тяжеловесов, таких как SELinux и AppArmor. Это как сцена, где два актёра борются за главную роль. Почему так происходит? Давай разберёмся в технических ловушках.

Эксклюзивность: один король на троне

Флаг, который разделяет судьбы

Главная причина конфликта SELinux и AppArmor — их эксклюзивный статус. В ядре Linux есть флаг, который делает модуль "единственным и неповторимым". SELinux и AppArmor оба помечены этим флагом, что означает: только один из них может быть активен. Это как два шеф-повара, борющихся за одну кухню: каждый хочет готовить по своему рецепту, и ядро не знает, кого слушать.

Эксклюзивность связана с тем, как ядро хранит контексты безопасности. Каждый процесс, файл или сокет получает "паспорт" — структуру данных, где хранится информация о его контексте. SELinux записывает туда метки, например system_u:object_r:httpd_sys_content_t:s0. AppArmor использует профили, привязанные к путям, вроде /usr/sbin/nginx. Но ядро выделяет только одно место для этого "паспорта". Это как пытаться уместить два письма в один конверт — они просто не влезут.

Я часто задаюсь вопросом: что, если ядро могло бы хранить два контекста? Но без серьёзной переработки это приведёт к хаосу. Если SELinux разрешает доступ, а AppArmor запрещает, кто прав? Это как два судьи, выносящие противоположные приговоры по одному делу.

Общие интерфейсы: борьба за микрофон

Ещё один барьер — общие интерфейсы ядра. Возьмём /proc/PID/attr/current. Этот интерфейс показывает контекст безопасности процесса. Для SELinux это метка, для AppArmor — имя профиля. Но что, если оба активны? Какой контекст отображать? Ядро не знает, и это создаёт конфликт.

То же с сокетами. Параметр SO_PEERSEC возвращает контекст безопасности сокета. SELinux выдаёт метку, AppArmor — профиль. Когда я впервые столкнулся с этим, я подумал: "Может, ядро могло бы возвращать оба контекста?" Но это потребовало бы переписать все инструменты, от ps до netstat. Это как заставить два радио играть разные мелодии через один динамик — получишь только шум.

Вот как проверить контекст в SELinux:

ps -Z

Пример вывода:

LABEL                             PID TTY          TIME CMD
unconfined_u:unconfined_r:unconfined_t:s0 1234 pts/0 00:00:01 bash

Для AppArmor:

aa-status

Вывод:

apparmor module is loaded.
10 profiles are loaded.
8 profiles are in enforce mode.
  /usr/sbin/nginx
  ...

Если оба модуля работают, ядро просто не справится с такой "какофонией".

Разные философии: метки против путей

SELinux и AppArmor — как два архитектора с разными чертежами. SELinux действует как библиотекарь, который метит каждую книгу (файл, процесс, сокет) и решает, кто может её взять. Его модель основана на субъектах и объектах, где доступ определяется политиками, привязанными к меткам. Это требует файловых систем с поддержкой расширенных атрибутов (xattrs), таких как ext4 или XFS. Настройка SELinux — это как сборка сложного пазла: каждая деталь должна быть на своём месте.

AppArmor, напротив, похож на охранника, проверяющего, по какому пути ты идёшь. Его политики привязаны к файлам, например:

/usr/sbin/nginx {
  /var/www/html/** r,
}

AppArmor не волнует файловая система, что делает его проще, но менее гибким. Когда я сравнивал их, мне казалось, что SELinux — это как проектирование всей инфраструктуры города, а AppArmor — установка замков на отдельные дома. Оба подхода хороши, но их слияние — это как попытка совместить акварель и чертежи в одном эскизе.

Эти различия создают проблему: как ядру понять, чья политика главнее? Если SELinux говорит "доступ разрешён", а AppArmor — "путь запрещён", система окажется в тупике. Это как два советника, дающих королю противоположные рекомендации.

Текущие барьеры: ядро не готово к дуэту

Ядро Linux пока не поддерживает одновременную работу двух эксклюзивных LSM, таких как SELinux и AppArmor. Это не потому, что никто не пытался. Разработчики уже давно работают над этой задачей, но перестройка ядра — это как ремонт двигателя на летящем самолёте. Текущая архитектура LSM позволяет активировать только один эксклюзивный модуль, и это ограничение унаследовано от ранних дней фреймворка.

Некоторые дистрибутивы, такие как Ubuntu, используют патчи для частичного стекинга. Например, в LXD хост может работать с SELinux, а контейнеры — с AppArmor. Я пробовал такую конфигурацию, и это было как балансирование на канате: всё работает, если каждый шаг выверен. Вот пример настройки SELinux для хоста:

semanage fcontext -a -t httpd_sys_content_t "/var/www/html(/.*)?"
restorecon -R -v /var/www/html

И профиля AppArmor для Nginx в контейнере:

include <tunables/global>
/usr/sbin/nginx {
  /var/www/html/** r,
  /var/log/nginx/* rw,
}

Но это не полноценный стекинг, а скорее обходное решение, требующее патчей и тонкой настройки.

Прогресс в стекинге LSM: свет в конце тоннеля

Патчи: Первые шаги к гармонии

Стекинг LSM — это как мост через пропасть, который строится годами. Патчи уже позволяют частичный стекинг в специфических сценариях, например, в контейнерах. Я видел, как это работает в LXD, где хост использует SELinux, а контейнеры — AppArmor. Это впечатляет, но не универсально. Эти патчи пока не в основном ядре, что ограничивает их доступность.

Проверить активные LSM можно так:

cat /sys/kernel/security/lsm

Вывод:

capability,selinux

Или:

capability,apparmor

Но selinux,apparmor вместе — это пока фантазия.

Будущее: многослойная защита

Я мечтаю о дне, когда ядро сможет обрабатывать несколько LSM одновременно. Это потребует:

• Новых структур данных для хранения нескольких контекстов.
• Модификации хуков LSM для вызова всех модулей.
• Логики разрешения конфликтов, например, "запрет имеет приоритет".

Представь, что ядро — как диспетчер, передающий запросы по цепочке модулей. SELinux проверяет метки, AppArmor — пути. Но это требует сложной координации. Что, если один модуль разрешает, а другой запрещает? Это как два врача, спорящих о лечении пациента. Решение потребует новых API и компромиссов в производительности.

Практические примеры в контейнерах

В контейнерах стекинг уже применяется. Например, в LXD хост с SELinux:

setenforce 1
semanage login -a -s user_u user

И контейнер с AppArmor:

aa-genprof /usr/sbin/nginx

Я пробовал такую конфигурацию, и она спасает, когда нужно изолировать приложения, но требует глубокого понимания обоих модулей.

Практическая настройка: как выжить с одним модулем?

Пока стекинг не стал стандартом, приходится выбирать. Вот примеры настройки Nginx.

SELinux:

1. Проверь режим:

getenforce

Вывод: Enforcing

2. Назначь метки:

semanage fcontext -a -t httpd_sys_content_t "/var/www/html(/.*)?"
restorecon -R -v /var/www/html

3. Разреши сетевые подключения:

setsebool -P httpd_can_network_connect 1

AppArmor:

1. Создай профиль:

sudo aa-genprof /usr/sbin/nginx

2. Отредактируй /etc/apparmor.d/usr.sbin.nginx:

include <tunables/global>
/usr/sbin/nginx {
  /var/www/html/** r,
  /var/log/nginx/* rw,
  capability net_bind_service,
}

3. Примени:

sudo aa-enforce /usr/sbin/nginx

Для нестандартного порта в SELinux:

semanage port -a -t http_port_t -p tcp 8080

В AppArmor:

network tcp 8080,

Эти примеры показывают, насколько разные подходы у модулей. SELinux требует тонкой настройки, AppArmor — проще, но ограничен.

Сравнение SELinux и AppArmor: твой выбор?

Чтобы понять, почему их сложно объединить, вот сравнение:

• Модель: SELinux — метки, AppArmor — пути.
• Сложность: SELinux сложен, AppArmor интуитивен.
• Файловые системы: SELinux требует xattrs, AppArmor — нет.
• Применение: SELinux для критических систем, AppArmor для быстрых решений.

SELinux — как броня танка, AppArmor — как лёгкий щит. Я советую новичкам начать с AppArmor, а опытным — освоить SELinux.

Перспективы: когда мечта станет реальностью?

Я верю, что стекинг LSM — это будущее. Представь систему, где SELinux защищает ядро, а AppArmor изолирует приложения. Это как двойной замок: один отпугивает, другой не пускает. Но для этого нужно:

• Переработать структуры данных для нескольких контекстов.
• Обновить хуки LSM.
• Создать новые API для отображения всех контекстов.

Это потребует компромиссов в производительности, но если сообщество справилось с namespaces, справится и здесь. Я часто думаю: как это изменит нашу работу? Мы сможем строить системы, где каждый модуль играет свою роль, как в слаженной команде.

Заключение: безопасность как шахматная партия

Работа с SELinux и AppArmor научила меня, что безопасность — это как шахматы: каждый ход требует расчёта. Нельзя просто включить оба модуля и надеяться на чудо. Эксклюзивность, конфликты интерфейсов и разные подходы делают это невозможным. Но патчи и эксперименты дают надежду. Пока же выбирай: мощь SELinux или простота AppArmor. Экспериментируй, следи за ядром и держи руку на пульсе. Безопасность — это не только код, но и умение видеть на шаг вперёд.