AppArmor — це простий і ефективний спосіб обмежити права процесів у Linux і зменшити шкоду від зламаного сервісу 🛡️. Якщо ви адмініструєте сервер Linux або просто хочете тримати систему в безпеці, давайте разом налаштуємо профілі AppArmor на Ubuntu/Debian: створимо, натренуємо на реальному трафіку, переведемо в enforce та навчимося робити безпечний відкат.

Підготовка: перевірка та інсталяція

Працюватимемо через термінал Linux і стандартні linux команди. Потрібні права sudo. Перевіримо, що ядро завантажене з підтримкою AppArmor, і доставимо утиліти:

sudo apt update
sudo apt install -y apparmor apparmor-utils apparmor-profiles apparmor-profiles-extra apparmor-notify

# Увімкнути та перевірити статус
sudo systemctl enable --now apparmor
sudo aa-status

# Переконатися, що AppArmor активний у ядрі
cat /sys/module/apparmor/parameters/enabled
# очікуємо: "Y" або "enforcing"/"complain" у виводі

Якщо AppArmor неактивний, перевірте параметри ядра:

cat /proc/cmdline | tr ' ' '\n' | grep -E 'apparmor|security'
# бажано бачити: apparmor=1 і security=apparmor

How-to: створюємо профіль для nginx (приклад сервісу)

Візьмемо популярний веб-сервер nginx. Логіка однакова для будь-якого демона: PostgreSQL, Redis, ваш systemd-сервіс тощо. Ми спочатку згенеруємо чорновий профіль, навчаємо його діями сервісу через log-файли Linux, а потім вмикаємо примусове застосування (enforce).

Крок 1: Чорновий профіль у режимі complain

# Встановити nginx, якщо ще не встановлено
sudo apt install -y nginx

# Дізнатися шлях до бінарника
which nginx
# очікуємо: /usr/sbin/nginx

# Створити чорновий профіль на основі залежностей
sudo aa-autodep /usr/sbin/nginx

# Перевести в режим скарг (збирає порушення, не блокує)
sudo aa-complain /usr/sbin/nginx

# Перезапустити сервіс, щоб згенерувати події
sudo systemctl restart nginx

Режим complain дає змогу побачити, чого бракує в політиці, не ламаючи роботу сервісу. Це дружній старт, особливо якщо мова про критичний сервер Linux.

Крок 2: Навчання через трафік і логи

Змусимо nginx попрацювати й зафіксувати доступи/заборони. Відкрийте кілька сторінок, статичні файли, спробуйте прокрутити логи.

# Згенерувати трафік
curl -I http://localhost/

# Подивитися події AppArmor у ядрових логах (зручно через journalctl)
journalctl -k -g apparmor --since -10m | tail -n +1
# або
dmesg | grep -i DENIED | tail -n 50

Тепер оновіть профіль на основі зібраних подій:

sudo aa-logprof
# Вас покроково запитають, дозволяти чи забороняти конкретні доступи.
# Обирайте найменші необхідні дозволи (принцип мінімальних привілеїв).

Крок 3: Переведення в enforce і перевірка

# Увімкнути примусове застосування політики
sudo aa-enforce /usr/sbin/nginx

# Перезавантажити всі профілі (або перезапустити сервіс)
sudo systemctl reload apparmor
sudo systemctl restart nginx

# Перевірити статус профілю
sudo aa-status | grep nginx

Пройдіться ще раз по функціоналу. Якщо щось ламається — загляньте в log-файли Linux і скористайтеся aa-logprof для дозаточування правил:

journalctl -k -g "apparmor|DENIED" --since -30m | less
sudo aa-logprof

Крок 4: Безпечний відкат (rollback)

Якщо після ввімкнення enforce сервіс почав падати, зробіть м'який відкат:

# Перевести профіль назад у complain
sudo aa-complain /usr/sbin/nginx
sudo systemctl reload apparmor

# За потреби тимчасово вимкнути профіль
sudo aa-disable /usr/sbin/nginx
sudo systemctl reload apparmor

Рекомендується тримати профілі під Git у /etc/apparmor.d/, щоб легко повертатися до стабільної версії:

cd /etc/apparmor.d
sudo git init
sudo git add .
sudo git commit -m "baseline: vendor + local profiles"
# ... редагуєте профіль ...
sudo git commit -am "tune: nginx allow static dir"
# Відкат:
sudo git checkout -- usr.sbin.nginx
sudo systemctl reload apparmor

Точкове видалення завантаженого профілю з ядра (якщо потрібно):

# Зняти профіль з ядра (розреєструвати)
sudo apparmor_parser -R /etc/apparmor.d/usr.sbin.nginx

Альтернативні способи профілювання

  • aa-genprof: інтерактивний генератор, який «водить за руку». Запускайте так: sudo aa-genprof /usr/sbin/your-binary і використовуйте сервіс, поки інструмент навчає профіль.
  • Використання include-абстракцій: у профілях є #include <abstractions/...> для поширених шаблонів (ssl, nameservice, apache2 тощо). Це скорочує політику і підвищує читабельність.
  • Тюнінг через локальні оверлеї: створюйте/редагуйте /etc/apparmor.d/local/usr.sbin.nginx, щоб не чіпати «vendor» файл. Так простіше робити оновлення пакунків і відкат.

GUI-спосіб (умовно)

На Ubuntu/Debian немає офіційної повноцінної GUI-консолі AppArmor (на відміну від YaST в openSUSE). Але ви можете:

  • Встановити apparmor-notify — отримаєте сповіщення на робочому столі, коли політика щось блокує.
  • Переглядати події в «Журнали» (GNOME Logs) і фільтрувати за «apparmor» або «DENIED».

Редагування самих політик і керування режимами все одно зручніше робити через термінал Linux.

FAQ

Як перевірити, що AppArmor реально працює?

Запустіть sudo aa-status — побачите завантажені профілі та їхні стани. Також гляньте cat /sys/module/apparmor/parameters/enabled і ядрові логи через journalctl -k -g apparmor.

Де шукати помилки та блокування?

Події AppArmor йдуть у ядрові log-файли Linux: використовуйте journalctl -k або dmesg. Шукайте рядки з «DENIED».

Чим відрізняються режими complain і enforce?

Complain реєструє порушення, але не блокує. Enforce примусово блокує заборонене та пише в логи. Профіль вчіть у complain, а в бойовій роботі тримайте в enforce.

Як змінити профіль після редагування файлів?

Виконайте sudo systemctl reload apparmor або перезавантажте конкретний профіль через apparmor_parser -r з шляхом до файлу.

Профілюю systemd-сервіс. Що вказувати як шлях?

У профілях AppArmor ключовим є шлях до бінарника з ExecStart (наприклад, /usr/sbin/nginx). Дивіться systemctl cat service або which <binary>.

Я зламала(в) SSH доступ профілем для sshd. Що робити?

На консолі сервера переведіть профіль у complain: sudo aa-complain /usr/sbin/sshd && sudo systemctl reload apparmor. На майбутнє — не вмикайте enforce для критичних сервісів без тестової сесії.

AppArmor vs SELinux?

AppArmor простіший і базується на шляхах до файлів, SELinux — на мітках. Для Ubuntu/Debian AppArmor — дефолт і зазвичай достатній для більшості задач.

Порада від Kernelka

💡 Тримайте профілі короткими і модульними: використовуйте include-абстракції та локальні оверлеї. Це спрощує обслуговування, оновлення пакунків і швидкий відкат без паніки.

Підсумок

  • Переконайтеся, що AppArmor увімкнено та встановлені утиліти.
  • Створіть чорновий профіль і потренуйте його в режимі complain.
  • Оновіть політику через aa-logprof, використовуючи реальні робочі сценарії.
  • Увімкніть enforce і перевірте функціонал сервісу.
  • Тримайте профілі під Git і знайте, як швидко відкотитися.
  • Дивіться ядрові логи для пошуку «DENIED» та точкового тюнінгу.

Так ви отримаєте практичний, мінімально привілейований захист сервісів без зайвого болю та з контрольованим відкатом ⚙️.