Модуль 29

SELinux та AppArmor (огляд)

Ось готовий урок, створений спеціально за твоїм запитом, у стилі енергійного та зрозумілого CS50.

🛡️ Урок: SELinux та AppArmor — Ваші цифрові охоронці

Привіт, друзі! 👋 Радий бачити вас на занятті.

Сьогодні ми поговоримо про тему, яка часто лякає новачків (і навіть досвідчених адмінів), змушуючи їх робити страшну річ — відключати безпеку. Ми говоримо про Mandatory Access Control (MAC), а саме про SELinux та AppArmor.

1. 🔥 Вступ: Чому звичайних прав доступу недостатньо?

Уявіть, що ви працюєте системним адміністратором у банку. У вас є вебсервер, скажімо, Nginx, який віддає сторінки клієнтам.

Ви налаштували все "по класиці": * Є користувач www-data. * У нього є права на папку /var/www/html. * Все працює.

Але одного разу хакер знаходить дірку у вашому вебсайті (наприклад, через вразливість у PHP-скрипті). Хакер перехоплює контроль над процесом Nginx. Тепер він — це користувач www-data.

Питання до вас: Що може зробити хакер, ставши www-data? Ну, він може читати все, що дозволено читати "всім" (other). Наприклад, залізти в /tmp, подивитися список процесів, спробувати запустити майнер.

Чому так стається? Бо класична система прав у Linux (DAC — Discretionary Access Control) працює за принципом: "Якщо у тебе є ключ від дверей, ти можеш зайти". Вона не питає, хто ти і що ти збираєшся там робити.

Тут на сцену виходять SELinux та AppArmor.

Уявіть їх як суворого охоронця 👮‍♂️, який стоїть за дверима. Навіть якщо у процесу Nginx є "ключ" (права rwx) до файлу /etc/shadow (гіпотетично) або до вашої домашньої папки, охоронець каже:

"Чекай-но. Ти — вебсервер. У твоїй посадовій інструкції написано 'віддавати HTML-сторінки'. Чому ти лізеш у домашню папку адміністратора? Доступ заборонено!"

Без цих систем, зламаний сервіс — це відкрите вікно в систему. З ними — це ізольована кімната, з якої не втекти.

2. 🧠 Теоретична база (Що там "під капотом"?)

Давайте розберемося без зайвої води. Є два головні гравці:

  1. SELinux (Security Enhanced Linux) — любить RedHat, CentOS, Fedora. Дуже потужний, працює на системі міток (labels).
  2. AppArmor (Application Armor) — любить Ubuntu, Debian, SUSE. Простіший, працює на основі шляхів до файлів.

Обидва реалізують MAC (Mandatory Access Control).

Як це працює?

Уявіть, що кожен файл і кожен процес у вашій системі має бейдж.

🦅 SELinux (Світ міток)

SELinux не цікавить, де лежить файл. Його цікавить, що написано на його бейджі (контексті).

  • Subject (Суб'єкт): Процес (нап. httpd).
  • Object (Об'єкт): Файл, порт, сокет.
  • Policy (Політика): Величезна книга правил у ядрі: "Суб'єкту з міткою A можна читати об'єкт з міткою B".

Що треба запам’ятати: В SELinux все вирішує Type (Тип). Це частина мітки, яка зазвичай закінчується на _t. Наприклад: httpd_t (процес вебсервера) може читати httpd_sys_content_t (файли сайту). Але він НЕ може читати ssh_home_t (ключі SSH).

🛡️ AppArmor (Світ профілів)

AppArmor працює простіше. Він дивиться на програму (наприклад, /usr/sbin/nginx) і читає її "профіль" (список дозволів).

  • Там написано: "Цій програмі можна читати /var/www/html/* і писати в /var/log/nginx/*".
  • Якщо програма спробує прочитати /root/secret.txt, AppArmor скаже: "Цього шляху немає в твоєму списку. Блок!".

3. 🧪 Приклади (Дивимось у реальності)

Приклад 1: SELinux у дії

Відкрийте термінал (якщо у вас RedHat-подібна система, або просто уявіть). Введіть команду ls -Z (Z — покажи контексти безпеки).

Ви очікуєте: Просто список файлів. Реальність:

-rw-r--r--. root root unconfined_u:object_r:admin_home_t:s0 anaconda-ks.cfg

Бачите admin_home_t? Це і є та сама мітка!

Приклад 2: "Інцидент з вебсервером"

Припустимо, ви створили новий файл для сайту, але поклали його в нестандартне місце: /srv/mysite/index.html. Ви налаштували Nginx, права chmod 755 дали.

Питання: Чи покаже Nginx цей файл? Інтуїція: Так, права ж є! SELinux: 🛑 403 Forbidden.

Чому? Тому що ви створили файл у /srv, і він отримав стандартну мітку для цієї папки (наприклад, var_t або default_t). А Nginx (процес httpd_t) має право читати тільки файли з міткою httpd_sys_content_t. Він приходить до файлу, показує свій бейдж, а ядро каже: "Вибач, ваші типи не сумісні".

Приклад 3: AppArmor (Ubuntu)

Давайте глянемо статус AppArmor. Команда: sudo aa-status

Ви побачите список процесів у режимі Enforce (Примус) або Complain (Скаржитись). * Enforce: Блокує дії і пише в лог. * Complain: Дозволяє дію, але пише в лог: "Агов, він зробив щось підозріле!". (Ідеально для навчання системи).

4. 🛠 Практична частина

Час закачати рукави! (Виконайте ці завдання на віртуальній машині, щоб не боятися зламати щось важливе).

Завдання 1: Розвідка 🕵️

Дізнайтеся, хто вас охороняє. * Якщо Ubuntu/Debian: введіть sudo aa-status. Скільки профілів завантажено? Скільки в режимі enforce? * Якщо CentOS/Fedora: введіть sestatus. Який режим поточний (Current mode)?

Завдання 2: Читання міток (SELinux) або Профілів (AppArmor)

  • SELinux: Зробіть ls -Z /var/www/html (або /var/log). Знайдіть частину, що закінчується на _t.
  • AppArmor: Зазирніть у папку /etc/apparmor.d/. Відкрийте будь-який файл (наприклад, для sbin.dhclient) через cat. Спробуйте знайти рядок, який починається з /var/... r,. Це означає "read permission".

Завдання 3: "Злови злочинця" (Робота з логами)

Уявіть, що щось не працює. Де шукати правду? * Спробуйте знайти лог аудиту. Зазвичай це /var/log/audit/audit.log або dmesg. * Спробуйте виконати команду: grep "denied" /var/log/audit/audit.log (або /var/log/syslog). * Якщо ви бачите там записи — вітаю, ваша система захисту працює і когось спіймала!

Завдання 4: Міні-кейс (Думковий експеримент) 🧠

Ви хочете запустити Nginx на порту 8088. Ви змінили конфіг Nginx, перезапустили, але він падає з помилкою. Права доступу в порядку. Порт вільний. У чому справа? (Підказка: SELinux дозволяє вебсерверу слухати лише певні порти, наприклад 80 і 443. 8088 у списку немає). Як би ви це виправили, не вимикаючи SELinux? (Гугліть: semanage port).

5. 💡 Мислення як у розробника

Ось тут я хочу, щоб ви мене почули дуже уважно.

🚫 Типова помилка новачка

Коли щось не працює (сайт не вантажиться, база не конектиться), перше, що радять на поганих форумах:

"Пропиши setenforce 0 або зупини AppArmor".

Це як зняти двері з петель, бо ключ заїдає. Так, ви зайдете всередину. Але і злодії теж. Ніколи не вимикайте MAC на проді!

🧠 Як думає профі

  1. Логи — це все. Якщо "Permission Denied", але chmod 777 не допомагає — це 100% SELinux/AppArmor.
  2. Permissive / Complain Mode. Замість вимкнення, переведіть захист у режим "тільки скаржитись".
    • Все запрацювало? Значить, проблема була в правилах.
    • Тепер читайте логи, дивіться, на що саме скаржилася система, і додайте це в дозволи.
  3. Принцип найменших привілеїв. Якщо програмі треба писати тільки в /tmp, не давайте їй доступ до всього /. AppArmor дозволяє це налаштувати дуже легко.

6. 🧩 Підсумок

Отже, що ми маємо в сухому залишку:

  1. DAC (chmod/chown) — це база, але її замало для сучасного захисту.
  2. SELinux/AppArmor — це ваша друга лінія оборони. Вони обмежують програми, навіть якщо їх запустили від root.
  3. SELinux фокусується на мітках (labels) і типах.
  4. AppArmor фокусується на шляхах до файлів.

Що ви тепер вмієте: Ви більше не боїтеся слів "SELinux context". Ви знаєте, що setenforce 0 — це шлях слабких. Ви знаєте, де шукати логи, коли "нічого не працює, але має".

🕵️‍♂️ Тизер наступного уроку: Сьогодні ми захищали процеси на одному сервері. А що, як нам треба ізолювати цілі операційні системи одна від одної, але без важких віртуалок? На наступному уроці ми поговоримо про Контейнеризацію та Docker, і ви побачите, що Docker насправді використовує ті самі механізми, які ми вивчили сьогодні!

До зустрічі! Кодуйте безпечно! 🚀

← До списку уроків Наступний урок →