SELinux и AppArmor - Mandatory Access Control

DAC vs MAC

• DAC (Discretionary Access Control) - обычные file-permissions, UID/GID/rwx. «Владелец решает кому что можно».
• MAC (Mandatory Access Control) - system-wide политика, юзеры её обойти не могут. «Этот процесс может писать ТОЛЬКО в эти пути, биндить ТОЛЬКО эти порты - независимо от того что в DAC».

Обе работают одновременно. Чтобы что-то разрешить - должны разрешить и DAC и MAC. Запретить - достаточно одного.

Реализация - Linux Security Modules (LSM): SELinux, AppArmor, SMACK, TOMOYO, Landlock. На системе обычно активен один.

SELinux

Распространён в RHEL/CentOS/Fedora/CoreOS. Работает с labels:

• Каждый процесс имеет context: user:role:type:level
• Каждый файл/сокет имеет такой же context
• Политика говорит «этот type может делать ЭТО с этим type'ом»

Самое важное - type (например, httpd_t для nginx, var_log_t для логов). Бесчисленные правила вроде «httpd_t may write httpd_log_t».

Просмотр

getenforce                          # Enforcing / Permissive / Disabled

sestatus                             # подробно

ls -Z /var/log/messages              # увидеть SELinux-context файла

ps -eZ | head                        # context процессов

id -Z                                # мой context

ausearch -m AVC -ts recent           # недавние denials в audit log

Режимы

• Enforcing - правила применяются, нарушения блокируются
• Permissive - правила НЕ применяются, но нарушения логируются (для отладки и сборки своего профиля)
• Disabled - отключено (требует ребута)

sudo setenforce 0                    # на лету в permissive

sudo setenforce 1                    # обратно в enforcing

# Постоянно - /etc/selinux/config: SELINUX=enforcing|permissive|disabled

Когда что-то ломается

Симптом: «обычный chmod 755 правильный, всё проверено, но nginx не читает файл». Подозрение SELinux:

sudo ausearch -m AVC -ts recent | tail -5

# type=AVC msg=audit(...): avc: denied { read } for pid=1234 comm="nginx"

#   ... scontext=system_u:system_r:httpd_t:s0

#   ... tcontext=unconfined_u:object_r:user_home_t:s0

Видим: httpd_t пытается читать user_home_t - запрещено. Решения:

• Перевесить правильный label: sudo chcon -t httpd_sys_content_t /path/file
• Постоянно: sudo semanage fcontext -a -t httpd_sys_content_t '/path(/.*)?'
  • sudo restorecon -Rv /path
• Создать кастомное правило (audit2allow):

sudo ausearch -m AVC -ts recent | audit2allow -M mymodule

sudo semodule -i mymodule.pp

AppArmor

Распространён в Ubuntu/Debian/SUSE. Работает с path-based профилями (а не labels). Профиль - это файл в /etc/apparmor.d/:

/usr/sbin/nginx {

  /etc/nginx/** r,

  /var/log/nginx/* w,

  /var/www/** r,

  network tcp,

  capability net_bind_service,

}

Бинарь привязан к профилю; что не разрешено - запрещено.

Просмотр

sudo aa-status                       # сводка: загруженные профили, режимы

cat /sys/kernel/security/apparmor/profiles

Режимы

• enforce - блокирует
• complain - логирует но не блокирует (= SELinux permissive для одного профиля)
• disabled

sudo aa-enforce /etc/apparmor.d/usr.sbin.nginx

sudo aa-complain /etc/apparmor.d/usr.sbin.nginx

sudo aa-disable /etc/apparmor.d/usr.sbin.nginx

Дебаг

Denials в kern.log / journal:

sudo dmesg | grep apparmor=

sudo journalctl -k | grep DENIED

Утилита aa-genprof <binary> - запускает программу в complain-режиме, собирает доступы, превращает в профиль. Очень удобно для написания своих профилей.

SELinux vs AppArmor

В контейнерах (Docker, podman, k8s) используются оба: профиль применяется к контейнерному процессу.

Когда отключают (и почему это плохо)

Соблазн: «не работает, выключу». Это снимает целый слой защиты. Лучше:

1. Перевести в permissive/complain (даст логи без блока)
2. Понять что именно denied
3. Скорректировать политику или label

Полное отключение разумно только если у тебя другая система изоляции (контейнеры + namespaces + seccomp + capabilities).

Связь со стеком

• MAC (SELinux/AppArmor) - что МОЖНО открыть/слушать/писать
• DAC (file-permissions) - обычные права
• capabilities - какие привилегии root есть
• seccomp - какие syscall'ы разрешены

Это четыре независимых слоя. Прод-серверы используют все четыре.