SELinux: Хватит делать setenforce 0. Учимся "читать" логи аудита

"Приложение не работает. Наверное, SELinux. setenforce 0... О, заработало! Готово".

Это — самый опасный рефлекс системного администратора. Вы только что отключили самый мощный механизм защиты в ядре Linux, который мог бы спасти вас от 0-day уязвимости.

SELinux (Security-Enhanced Linux) — это Mandatory Access Control (MAC). Он не дает root-процессу, если он скомпрометирован (например, Nginx), читать /etc/shadow. Он работает по принципу "запрещено всё, что явно не разрешено политикой".

Проблема: Как "разрешить", не отключая всю систему? Решение: auditd и audit2allow.

План "Архитектора" по решению SELinux-проблемы (на 3 минуты):

Сценарий: Ваш Nginx не может прочитать файлы в /srv/www/html. Вы видите Permission Denied.

1. Проверьте, что это SELinux:
Bash

# Временно переводим в "разрешающий" режим (только логи, без блокировки)
sudo setenforce 0

# Проверяем, заработало ли приложение. Если да — виновник 100% SELinux.

# ВОЗВРАЩАЕМ ЗАЩИТУ!
sudo setenforce 1

2. Находим причину в логах аудита: auditd пишет все "denied" в /var/log/audit/audit.log.
Bash

# Находим все отказы SELinux за последнее время
sudo ausearch -m AVC -ts recent

# ...или "классика"
sudo grep "denied" /var/log/audit/audit.log | tail -n 5

Вы увидите строку, где comm="nginx" (процесс) пытался read (действие) на path="/srv/www/html/index.html" (цель).

3. Генерируем "исключение" (магия): Утилита audit2allow читает этот лог и сама пишет модуль политики за вас.
Bash

# 1. Собираем все недавние отказы в один файл
sudo ausearch -m AVC -ts recent > /tmp/nginx_denials.log

# 2. Генерируем модуль (myNginxFix)
sudo audit2allow -M myNginxFix -i /tmp/nginx_denials.log

# 3. Устанавливаем этот модуль в политику
sudo semodule -i myNginxFix.pp

Готово. Вы не "отключили" безопасность. Вы уточнили политику, разрешив только Nginx читать только вашу папку.

Взгляд архитектора: setenforce 0 — это признание поражения. semodule -i ... — это инженерное решение. Архитектор управляет политиками безопасности, а не отключает их. Это и есть Principle of Least Privilege (Принцип наименьших привилегий) в действии.

#linux #security #selinux #audit #sre #гайд #musthave

🐧 Linux: AppArmor vs SELinux в 2026 — выбор который влияет на безопасность при следующем Copy Fail

Коллеги, Copy Fail дал нам хороший повод поговорить о вещи которую большинство откладывает. SELinux и AppArmor работали в режиме enforcing на ваших серверах в момент атаки? Или были отключены "потому что мешают"?

Одна из самых распространённых ошибок — отключить SELinux или AppArmor при первых проблемах. Вместо этого нужно использовать permissive (SELinux) или complain (AppArmor) режимы для отладки. Отключение этих слоёв оставляет систему открытой для атак повышения привилегий.

Быстрый выбор: SELinux — для RHEL/Rocky/AlmaLinux, AppArmor — для Ubuntu/Debian. Это не холивар, это дефолт дистрибутива.

# ---- APPARMOR (Ubuntu/Debian) ----
# Проверяем статус:
aa-status
apparmor_status | grep -E "profiles|processes"

# Включаем enforce для конкретного сервиса:
aa-enforce /etc/apparmor.d/usr.sbin.nginx
systemctl reload apparmor

# Смотрим нарушения в логах (complain mode — для диагностики):
aa-complain /etc/apparmor.d/usr.sbin.nginx
journalctl -k | grep apparmor | tail -20

# Создаём профиль для нового сервиса:
aa-genprof /usr/local/bin/myapp
# Запускаем сервис, делаем типичные операции, останавливаем
# aa-genprof предложит профиль на основе реального поведения

# ---- SELINUX (RHEL/Rocky/AlmaLinux) ----
# Проверяем статус:
getenforce  # Enforcing / Permissive / Disabled
sestatus

# Если Disabled — включаем через /etc/selinux/config:
sed -i 's/SELINUX=disabled/SELINUX=enforcing/' /etc/selinux/config
# Перезагрузка обязательна. Сначала переводим в Permissive:
sed -i 's/SELINUX=disabled/SELINUX=permissive/' /etc/selinux/config

# Смотрим что SELinux блокирует:
ausearch -m AVC -ts recent | tail -30
# Генерируем политику под конкретный deny:
ausearch -m AVC -ts recent | audit2allow -M mypolicy
semodule -i mypolicy.pp

# Проверяем нет ли процессов без confinement:
ps -eZ | grep unconfined_t

Начинайте с complain/permissive режима для одного конкретного сервиса, собирайте события под реальной нагрузкой, затем переводите в строгий режим. Резкое включение enforcing для всего почти гарантированно сломает что-то неочевидное — unix-сокеты, временные директории, кастомные пути логов.

Зачем именно сейчас:
Copy Fail требует локального доступа — но что если атакующий уже внутри через другую уязвимость? SELinux/AppArmor в enforcing ограничивает что может сделать скомпрометированный процесс даже с root-привилегиями.

Итог: запусти getenforce или aa-status прямо сейчас. Если не Enforcing — у тебя есть задача на эту пятницу.

#linux #apparmor #selinux #security #hardening #sysadmin #admin_future