Одна з причин грандіозного успіху Linux ОС на вбудованих, мобільних пристроях і серверах полягає у досить високому ступені безпеки ядра, супутніх служб та додатків. Але якщо до архітектури ядра Linux, то не можна в ньому знайти квадратик, що відповідає за безпеку, як таку. Де ж ховається підсистема безпеки Linux і чого вона складається?
Передісторія Linux Security Modules та SELinux
Security Enhanced Linux є набором правил і механізмом доступу, заснований на моделях мандатного та рольового доступу, для захисту систем Linux від потенційних загроз та виправлення недоліків Discretionary Access Control (DAC) — традиційної системи безпеки Unix. Проект зародився в надрах Агентства Національної Безпеки США, безпосередньо розробкою займалися в основному підрядники Secure Computing Corporation і MITRE, а також низка дослідних лабораторій.
Модулі безпеки Linux
Лінус Торвальдс вніс ряд зауважень про нові розробки АНБ, щоб їх можна було включити в основну гілку ядра Linux. Він описав загальне середовище, з набором перехоплювачів управління операціями з об'єктами і набором деяких захисних полів у структурах даних ядра для зберігання відповідних атрибутів. Потім це середовище може використовуватися модулями ядра, що завантажуються, для реалізації будь-якої бажаної моделі безпеки. LSM повноцінно увійшов у ядро Linux v2.6 у 2003 році.
Фреймворк LSM включає захисні поля в структурах даних та виклики функцій перехоплення в критичних точках коду ядра для управління ними та контролю доступу. Він також додає функції реєстрації модулів безпеки. Інтерфейс /sys/kernel/security/lsm містить список активних модулів у системі. Хуки LSM зберігаються у списках, які викликаються у порядку, зазначеному у CONFIG_LSM. Детальна документація по хуках включена до заголовка include/linux/lsm_hooks.h.
Підсистема LSM дозволила завершити повноцінну інтеграцію SELinux тієї самої версії стабільного ядра Linux v2.6. Буквально відразу ж SELinux став стандартом де-факто захищеного середовища Linux і увійшов до складу найбільш популярних дистрибутивів: RedHat Enterprise Linux, Fedora, Debian, Ubuntu.
Глосарій SELinux
- ідентичність — Користувач SELinux не те саме, що і звичний Unix/Linux user id, вони можуть співіснувати на одній і тій же системі, але зовсім різні по суті. Кожен стандартний обліковий запис Linux може відповідати одному або декільком SELinux. Ідентичність SELinux є складовою загального контексту безпеки, який визначає які домени можна входити, а які — не можна.
- Домени - У SELinux домен є контекстом виконання суб'єкта, тобто процесу. Домен безпосередньо визначає доступ, який має процес. Домен - це в основному список того, що можуть робити процеси або які дії може виконувати з різними типами. Деякі приклади доменів: sysadm_t для системного адміністрування та user_t, який є звичайним непривілейованим доменом користувача. Система ініціалізації init запускається в домені init_t, а процес named запускається в домені named_t.
- ролі — Те, що є посередником між доменами та користувачами SELinux. Ролі визначають, у яких домени може полягати користувач і яких типів об'єктів він зможе отримати доступ. Подібний механізм розмежування доступів запобігає загрозі атаки підвищення привілеїв. Ролі вписані в модель безпеки Role Based Access Control (RBAC), яка використовується в SELinux.
- Типи — Атрибут списку Type Enforcement, який призначається об'єкту та визначає, хто отримає доступ до нього. Схоже визначення домену, за винятком того, що домен застосовується до процесу, а тип застосовується до таких об'єктів, як каталоги, файли, сокети і т.д.
- Суб'єкти та об'єкти — Процеси є суб'єктами і запускаються у певному контексті чи домені безпеки. Ресурси операційної системи: файли, директорії, сокети та ін. є об'єктами, яким ставиться у відповідність певний тип, інакше кажучи — рівень секретності.
- Політики SELinux — Для захисту системи SELinux використовує різноманітні політики. Політика SELinux визначає доступ користувачів до ролей, ролей до доменів і доменів до типів. Спочатку авторизується для отримання ролі, далі роль авторизується для доступу до доменів. Нарешті, домен може мати доступ лише до деяких типів об'єктів.
LSM та архітектура SELinux
Незважаючи на назву LSM загалом не є модулями Linux, що завантажуються. Однак, як і SELinux, він безпосередньо інтегрований в ядро. Будь-яка зміна вихідного коду LSM вимагає нової компіляції ядра. Відповідна опція повинна бути увімкнена в налаштуваннях ядра, інакше код LSM не буде активований після завантаження. Але навіть у цьому випадку його можна увімкнути опцією завантажувача ОС.
Стек перевірок LSM
LSM оснащений хуками в основні функції ядра, які можуть бути релевантними для перевірок. Однією з основних особливостей LSM є те, що вони влаштовані за принципом стека. Таким чином, стандартні перевірки, як і раніше, виконуються, і кожен шар LSM лише додає додаткові елементи управління та контролю. Це означає, що заборону неможливо відкотити назад. Це показано на малюнку, якщо результатом рутинних перевірок DAC стане відмова, то справа навіть не дійде до хуків LSM.
SELinux перейняв архітектуру безпеки Flask дослідницької операційної системи Fluke, зокрема принцип найменших привілеїв. Суть цієї концепції, як слід їх назви, у наданні користувачеві або процесу лише тих прав, які необхідні здійснення гаданих дій. Даний принцип реалізований за допомогою примусової типізації доступу, таким чином контроль допусків SELinux базується на моделі домен => тип.
Завдяки примусовій типізації доступу SELinux має набагато значніші можливості розмежування доступу, ніж традиційна модель DAC, що використовується в ОС Unix/Linux. Наприклад, можна обмежити номер мережного порту, який траплятиме ftp сервер, дозволити запис і зміни файлів у певній папці, але з їх видалення.
Основні компоненти SELinux такі:
- Policy Enforcement Server - Основний механізм організації контролю доступу.
- БД політик безпеки системи.
- Взаємодія з перехоплювачем подій LSM.
- Selinuxfs - Псевдо-ФС, така сама, як /proc і примонтована в /sys/fs/selinux. Динамічно заповнюється ядром Linux під час виконання та містить файли, що містять відомості про статус SELinux.
- Access Vector Cache - Допоміжний механізм підвищення продуктивності.
Схема роботи SELinux
Все це працює в такий спосіб.
- Якийсь суб'єкт, у термінах SELinux, виконує над об'єктом дозволену дію після DAC перевірки, як показано на верхній картинці. Цей запит виконання операції потрапляє до перехоплювача подій LSM.
- Звідти запит разом із контекстом безпеки суб'єкта і об'єкта передається модуль SELinux Abstraction and Hook Logic, відповідальний за взаємодію Космосу з LSM.
- Інстанцією прийняття рішення про доступ суб'єкта до об'єкта є Policy Enforcement Server і до нього надходять дані SELinux AnHL.
- Для ухвалення рішення про доступ або заборону Policy Enforcement Server звертається до підсистеми кешування найбільш використовуваних правил Access Vector Cache (AVC).
- Якщо рішення для відповідного правила не знайдено в кеші, запит передається далі в БД політик безпеки.
- Результат пошуку з БД та AVC повертається до Policy Enforcement Server.
- Якщо знайдена політика узгоджується із запитуваною дією, то операція дозволяється. В іншому випадку операція забороняється.
Управління налаштуваннями SELinux
SELinux працює в одному з трьох режимів:
- Enforcing - Суворе дотримання політик безпеки.
- Permissive — Допускається порушення обмежень, у журналі робиться відповідна позначка.
- Disabled — Політики безпеки не діють.
Подивитися в якому режимі SELinux можна наступною командою.
[admin@server ~]$ getenforce
PermissiveЗміна режиму до перезавантаження, наприклад виставити на enforcing, або 1. Параметру permissive відповідає числовий код 0.
[admin@server ~]$ setenfoce enforcing
[admin@server ~]$ setenfoce 1 #то же самое
Також можна змінити режим виправлення файлу:
[admin@server ~]$ cat /etc/selinux/config
# This file controls the state of SELinux on the system.
# SELINUX= can take one of these three values:
# enforcing - SELinux security policy is enforced.
# permissive - SELinux prints warnings instead of enforcing.
# disabled - No SELinux policy is loaded.
SELINUX=enforcing
# SELINUXTYPE= can take one of three values:
# targeted - Targeted processes are protected,
# minimum - Modification of targeted policy. Only selected processes are protected.
# mls - Multi Level Security protection.
SELINUXTYPE=targete
Різниця з setenfoce в тому, що при завантаженні операційної системи режим SELinux буде виставлений відповідно до значення параметра SELINUX конфігураційного файлу. Крім того, зміни enforcing <=> disabled набирають чинності тільки через виправлення файлу /etc/selinux/config і після перезавантаження.
Переглянути короткий статусний звіт:
[admin@server ~]$ sestatus
SELinux status: enabled
SELinuxfs mount: /sys/fs/selinux
SELinux root directory: /etc/selinux
Loaded policy name: targeted
Current mode: permissive
Mode from config file: enforcing
Policy MLS status: enabled
Policy deny_unknown status: allowed
Max kernel policy version: 31
Для перегляду атрибутів SELinux деякі штатні утиліти використовують параметр -Z.
[admin@server ~]$ ls -lZ /var/log/httpd/
-rw-r--r--. root root system_u:object_r:httpd_log_t:s0 access_log
-rw-r--r--. root root system_u:object_r:httpd_log_t:s0 access_log-20200920
-rw-r--r--. root root system_u:object_r:httpd_log_t:s0 access_log-20200927
-rw-r--r--. root root system_u:object_r:httpd_log_t:s0 access_log-20201004
-rw-r--r--. root root system_u:object_r:httpd_log_t:s0 access_log-20201011
[admin@server ~]$ ps -u apache -Z
LABEL PID TTY TIME CMD
system_u:system_r:httpd_t:s0 2914 ? 00:00:04 httpd
system_u:system_r:httpd_t:s0 2915 ? 00:00:00 httpd
system_u:system_r:httpd_t:s0 2916 ? 00:00:00 httpd
system_u:system_r:httpd_t:s0 2917 ? 00:00:00 httpd
...
system_u:system_r:httpd_t:s0 2918 ? 00:00:00 httpdПорівняно із звичайним висновком ls -l тут є кілька додаткових полів наступного формату:
<user>:<role>:<type>:<level>
Останнє поле позначає щось на зразок грифу секретності і складається з комбінації двох елементів:
- s0 - значимість, також записують інтервалом lowlevel-highlevel
- c0, c1 ... c1023 - категорія.
Зміна конфігурації доступів
Використовуйте semodule, щоб завантажувати модулі SELinux, додавати та видаляти їх.
[admin@server ~]$ semodule -l |wc -l #список всех модулей
408
[admin@server ~]$ semodule -e abrt #enable - активировать модуль
[admin@server ~]$ semodule -d accountsd #disable - отключить модуль
[admin@server ~]$ semodule -r avahi #remove - удалить модульПерша команда semanage login пов'язує користувача SELinux із користувачем операційної системи, друга виводить список. Нарешті остання команда з ключем -r видаляє зв'язку відображення користувачів SELinux на облікові записи операційної системи. Пояснення синтаксису значень MLS/MCS Range міститься у попередньому розділі.
[admin@server ~]$ semanage login -a -s user_u karol
[admin@server ~]$ semanage login -l
Login Name SELinux User MLS/MCS Range Service
__default__ unconfined_u s0-s0:c0.c1023 *
root unconfined_u s0-s0:c0.c1023 *
system_u system_u s0-s0:c0.c1023 *
[admin@server ~]$ semanage login -d karol
Команда semanage user використовується для керування відображень між користувачами та ролями SELinux.
[admin@server ~]$ semanage user -l
Labeling MLS/ MLS/
SELinux User Prefix MCS Level MCS Range SELinux Roles
guest_u user s0 s0 guest_r
staff_u staff s0 s0-s0:c0.c1023 staff_r sysadm_r
...
user_u user s0 s0 user_r
xguest_u user s0 s0 xguest_r
[admin@server ~]$ semanage user -a -R 'staff_r user_r'
[admin@server ~]$ semanage user -d test_uПараметри команди:
- -a додати запис користувача відповідності ролей;
- -l список відповідності користувачів та ролей;
- -d видалити запис користувача відповідності ролей;
- -R список ролей, прикріплених до користувача;
Файли, порти та булеві значення
Кожен модуль SELinux надає набір правил маркування файлів, але також можна додати власні правила у разі потреби. Наприклад, ми бажаємо дати веб-серверу права доступу до папки /srv/www.
[admin@server ~]$ semanage fcontext -a -t httpd_sys_content_t "/srv/www(/.*)?
[admin@server ~]$ restorecon -R /srv/www/Перша команда реєструє нові правила маркування, а друга скидає, вірніше виставляє типи файлів відповідно до поточних правил.
Аналогічно, TCP/UDP порти зазначені в такий спосіб, що лише відповідні послуги можуть їх прослуховувати. Наприклад, щоб веб-сервер міг прослуховувати порт 8080, потрібно виконати команду.
[admin@server ~]$ semanage port -m -t http_port_t -p tcp 8080Значна кількість модулів SELinux мають параметри, які можуть набувати булевих значень. Увесь список таких параметрів можна побачити за допомогою getsebool-a. Змінювати булеві значення можна за допомогою setsebool.
[admin@server ~]$ getsebool httpd_enable_cgi
httpd_enable_cgi --> on
[admin@server ~]$ setsebool -P httpd_enable_cgi off
[admin@server ~]$ getsebool httpd_enable_cgi
httpd_enable_homedirs --> off
Практикум, отримати доступ до інтерфейсу Pgadmin-web
Розглянемо приклад з практики, що ми встановили на RHEL 7.6 pgadmin4-web для адміністрування БД PostgreSQL. Ми пройшли невеликий з налаштуванням pg_hba.conf, postgresql.conf і config_local.py, виставили права на папки, встановили з pip відсутні модулі Python. Все готове, запускаємо та отримуємо 500 Внутрішня помилка сервера.
Починаємо з типових підозрюваних, перевіряємо /var/log/httpd/error_log. Там є деякі цікаві записи.
[timestamp] [core:notice] [pid 23689] SELinux policy enabled; httpd running as context system_u:system_r:httpd_t:s0
...
[timestamp] [wsgi:error] [pid 23690] [Errno 13] Permission denied: '/var/lib/pgadmin'
[timestamp] [wsgi:error] [pid 23690]
[timestamp] [wsgi:error] [pid 23690] HINT : You may need to manually set the permissions on
[timestamp] [wsgi:error] [pid 23690] /var/lib/pgadmin to allow apache to write to it.
На цьому місці у більшості адміністраторів Linux виникне стійка спокуса запустити setencorce 0, та й справа з кінцем. Зізнатись, уперше я так і зробив. Це, звичайно, теж вихід, але далеко не найкращий.
Незважаючи на громіздкість конструкцій SELinux може бути дружнім до користувача. Достатньо встановити пакет setroubleshoot і переглянути системний журнал.
[admin@server ~]$ yum install setroubleshoot
[admin@server ~]$ journalctl -b -0
[admin@server ~]$ service restart auditd
Зверніть увагу на те, що сервіс auditd необхідно перезапускати саме так, а не за допомогою systemctl, незважаючи на наявність systemd в ОС. У системному журналі буде вказано не тільки факт блокування, але також причина і спосіб подолання заборони.
Виконуємо ці команди:
[admin@server ~]$ setsebool -P httpd_can_network_connect 1
[admin@server ~]$ setsebool -P httpd_can_network_connect_db 1
Перевіряємо доступ на веб-сторінку pgadmin4-web, все працює.
Джерело: habr.com