1. Передмова
Security-Enhanced Linux (SELinux) — це модуль ядра Linux і підсистема безпеки Linux.
SELinux був переважно розроблений NSA. Ядра Linux 2.6 і вище вже інтегрують модулі SELinux.
SELinux дуже складний і містить багато концептуальних речей, які важко вивчити. Багато системних адміністраторів Linux вимкнули SELinux, бо вважають це проблемним.
Якщо ви опануватимете SELinux і правильно ним користуватися, я думаю, що вся система може дійти до рівня «незнищенності» (завжди пам'ятайте, що абсолютної безпеки не існує).
Опанування базових концепцій SELinux, а також простих методів конфігурації є обов'язковим курсом для кожного системного адміністратора Linux.
Ця стаття базується на CentOS 7.4.1708.
Ця стаття — виключно особистий навчальний досвід, обмін і обмін, помилки неминучі, лише для довідки! Якщо знайдете помилку, будь ласка, зверніть на неї, дуже дякую!
2. Роль SELinux та механізм управління дозволами
2.1 Роль SELinux
Основна функція SELinux — мінімізувати ресурси, до яких можуть отримати сервісні процеси в системі (принцип найменших привілеїв).
Уявіть, що якщо мережевий сервіс, що працює як root, має вразливість 0day, хакери можуть використати цю вразливість, щоб робити все, що забажають, на вашому сервері як root. Хіба це не страшно?
SELinux тут, щоб вирішити цю проблему.
2.2 DAC
В операційній системі, яка не використовує SELinux, фактором, що визначає, чи можна отримати доступ до ресурсу, є права відповідного користувача (читання, запис, виконання).
Поки процес, що отримує доступ до цього ресурсу, відповідає вищезазначеним умовам, до нього можна отримати доступ.
Найфатальніша проблема полягає в тому, що користувачі root не підпадають під жодне регулювання, і будь-які ресурси системи доступні без обмежень.
Основною частиною цього механізму управління дозволами є користувач, також відомий як автономний контроль доступу (DAC).
2.3 MAC
В операційній системі, що використовує SELinux, фактори, які визначають, чи можна отримати доступ до ресурсу, — це не лише вищезазначені фактори, а й те, чи має кожен тип процесу доступ до певного типу ресурсу.
Таким чином, навіть якщо процес працює як root, необхідно визначити тип процесу та типи ресурсів, до яких можна отримати доступ, перш ніж вирішувати, чи дозволяти їм доступ до ресурсу. Активний простір процесу також можна мінімізувати до мінімуму.
Навіть сервісний процес, що працює як root, зазвичай має доступ лише до необхідних ресурсів. Навіть якщо програма вразлива, масштаб впливу обмежується ресурсами, до яких їй дозволено мати доступ. Безпека значно посилена.
Основною частиною цього механізму управління дозволами є процес, також відомий як обов'язковий контроль доступу (MAC).
MAC поділяється на два способи: один називається режимом категорійної безпеки (MCS), а інший — режимом багаторівневої безпеки (MLS).
Наступні дії знаходяться в режимі MCS.
2.4 Порівняння ЦАП і MAC
Ось фото для ілюстрації.
Як бачите, у режимі ЦАП, якщо відповідний каталог має права відповідного користувача, до нього можна отримати доступ. У режимі MAC він також обмежений діапазоном каталогів, до яких процеси мають доступ.
3. Основні поняття SELinux
3.1 Тема
Це можна повністю прирівняти до певного процесу.
Примітка: Для зручності розуміння, якщо не вказано інше, цей процес розглядається як основна частина нижче.
3.2 Мета
Ресурси, доступні директором. Це можуть бути файли, каталоги, порти, пристрої тощо.
Примітка: Для зручності розуміння, якщо не вказано інше, наступні документи або каталоги розглядаються як об'єкти.
3.3 Політика та правила
Зазвичай у системі є велика кількість файлів і процесів, і щоб зекономити час і витрати, ми зазвичай вибірково регулюємо лише певні процеси.
А які процеси потрібно регулювати і як їх контролювати — визначається політикою.
У полісі існує кілька правил. Деякі правила можна увімкнути або вимкнути за потреби (далі — булеві правила).
Правила модульні та розширюються. Під час встановлення нового додатку додаток може додавати правила, додаючи нові модулі. Користувачі також можуть вручну додавати або віднімати правила.
У системі CentOS 7 існує три набори політик, а саме:
1. цільова: Контролює більшість процесів мережевого обслуговування. Це політика, яку система використовує за замовчуванням (усі наведені нижче).
2. Мінімум: На основі цільових рішень регулюються лише вибрані процеси мережевого сервісу. Зазвичай ні.
3. MLS: багаторівневий захист безпеки. Регулювати всі процеси. Це найсуворіша політика, і конфігурація дуже складна. Зазвичай його не використовують, якщо немає надзвичайно високих вимог до безпеки.
Політики можна встановлювати у /etc/selinux/config.
3.4 Контекст безпеки
Контекст безпеки лежить у центрі SELinux.
Контекст безпеки я поділяю його на «контекст безпеки процесу» та «контекст безпеки документів».
Контекст безпеки процесу зазвичай відповідає кільком контекстам безпеки документів.
Лише коли контекст безпеки цих двох відповідає, процес може отримати доступ до файлу. Їхня відповідність визначається правилами полісу.
Контекст безпеки файлу визначається місцем створення файлу та процесом, який його створив. Система має набір значень за замовчуванням, і користувачі також можуть встановлювати ці значення.
Важливо зазначити, що просте переміщення файлів не змінює їхній контекст безпеки.
Структура та значення контексту безпеки
Контекст безпеки має чотири поля, розділені двокрапками. Форма, наприклад: system_u:object_r:admin_home_t:s0.
3.5 Робочий режим SELinux
SELinux має три режими роботи, а саме:
1. примус: режим примусового використання. Порушення правил SELinux будуть заблоковані та внесені в логи.
2. Дозвільне: режим толерантності. Порушення правил SELinux фіксуються лише в журналах. Зазвичай для налагодження.
3. вимкнено: вимкнути SELinux.
Робочий режим SELinux можна встановити у /etc/selinux/config.
Якщо ви хочете перейти з «вимкненого» на «примусовий» або «дозволений», вам потрібно перезавантажити систему. І навпаки.
Режими Enenforce та Permissive можна швидко перемикати за допомогою команди Setenforce 1|0.
Важливо зазначити, що якщо система працювала з вимкненим SELinux деякий час, перше перезавантаження після ввімкнення SELinux може бути повільніше. Тому що система має створити безпечний контекст для файлів на диску (я казав, що перезавантажив приблизно 10 хвилин і думав, що він мертвий...... ）。
Логи SELinux потрібно логувати за допомогою auditd.service, будь ласка, не вимикайте це.
3.6 Робочий процес SELinux
Ось цитата з фотографії, без особливих пояснень.
Примітка: Текст безпеки вище стосується контексту безпеки.
4. Базові операції SELinux
4.1 Запит до контексту безпеки файлу або каталогу
Базове використання команд
ls -Z
Приклади використання
Запит у контексті безпеки /etc/hosts.
ls -Z /etc/hosts
Результати виконання
-Рв-р--р--. кореневий корінь system_u:object_r:net_conf_t:s0 /etc/hosts
4.2 Запит до контексту безпеки процесу
Базове використання команд
ps auxZ | grep -v grep | grep
Приклади використання
Запит у контексті безпеки процесів, пов'язаних із Nginx.
ps auxZ | grep -v grep | grep nginx
Результати виконання
system_u:system_r:httpd_t:s0 root 7997 0.0 0.0 122784 2156 ? Пс 14:31 0:00 nginx: головний процес /usr/sbin/nginx
system_u:system_r:httpd_t:s0 nginx 7998 0.0 0.0 125332 7560 ? S 14:31 0:00 nginx: робочий процес
4.3 Ручне змінювати контекст безпеки файлу або каталогу
Базове використання команд
CHCON [...]
Опціональна функція -u Змінити поле користувача контексту безпеки -r Змінити поле ролі контексту безпеки -t Змінити поле типу контексту безпеки -l Змінити поле рівня контексту безпеки --посилання Змінити контекст безпеки відповідно до вказаного файлу або каталогу -R Рекурсивна операція -h Змінити контекст безпеки м'якого посилання (змінити відповідний файл м'якого посилання без цієї опції)
Приклади використання
Змініть контекст безпеки тесту на aaa_u:bbb_r:ccc_t:s0.
chcon -u aaa_u -r bbb_r -t ccc_t тест
4.4 Повернути контекст безпеки файлу або каталогу до його значення за замовчуванням
Базове використання команд
Restorecon [Опції] [...]
Опціональна функція - процедура операції друку V - рекурсивна операція R
Приклади використання
Після додавання веб-файлів до каталогу вашого сервера Nginx встановіть правильний контекст безпеки для цих нових файлів.
restorecon -R /usr/share/nginx/html/
4.5 Запит булевих правил та їхній статус у системі
Базове використання команд
getsebool -a
Оскільки команда запитує або всі правила, або лише одне, зазвичай спочатку виконує всі правила, а потім фільтрує за допомогою grep.
Приклади використання
Запит у булевих правилах, пов'язаних із httpd.
гетсебул -а | GREP HTTPD
Результати виконання
httpd_anon_write > геть
httpd_builtin_scripting --> далі
httpd_can_check_spam > геть
httpd_can_connect_ftp — > геть
#以下省略
4.6 Зміна булевого правила
Базове використання команд
setsebool [опція]
Опціональна функція -P перезапуск все одно діє
Приклади використання
Увімкніть httpd_anon_write правила.
setsebool -P httpd_anon_write on
4.7 Додати стандартний контекст безпеки для каталогу
Базове використання команд
semanage fcontext -a -t "(/.*)?"
Примітка: Стандартний контекст безпеки каталогу або файлу можна переглянути, використовуючи команду semanage fcontext -l разом із фільтрацією grep.
Приклади використання
Після додавання нового каталогу сайту /usr/share/nginx/html2 до Nginx потрібно встановити той самий стандартний контекст безпеки, що й оригінальний каталог.
semanage fcontext -a -t httpd_sys_content_t "/usr/share/nginx/html2(/.*)?"
4.8 Додати порти, дозволені певними типами процесів
Базове використання команд
semanage port -a -t -p
Примітка: Номери портів, дозволені для різних типів сервісів, можна переглянути, використовуючи команду semanage port -l з фільтрацією grep.
Приклади використання
Для Nginx потрібно використовувати порт 10080 для HTTP-сервісів.
SEMANAGE Port -A -T http_port_t -P TCP 10080
5. Аналіз помилок SELinux та розв'язання
5.1 Розуміння логів SELinux
Коли SELinux увімкнено, деяка нормальна поведінка багатьох сервісів вважається порушенням (як у заголовку, так і в помилках нижче).
Наразі нам потрібно використовувати журнали порушень SELinux для їх аналізу та розв'язання.
Журнали порушень SELinux зберігаються у /var/log/audit/audit.log.
/var/log/audit/audit.log 的内容大概是这样的。
type=LOGIN msg=audit(1507898701.391:515): pid=8523 uid=0 subj=system_u:system_r:crond_t:s0-s0:c0.c1023 old-auid=4294967295 auid=0 tty=(none) old-ses=4294967295 ses=25 res=1
type=USER_START msg=audit(1507898701.421:516): pid=8523 uid=0 auid=0 ses=25 subj=system_u:system_r:crond_t:s0-s0:c0.c1023 msg='op=PAM:session_open grantors=pam_loginuid,pam_ keyinit,pam_limits,pam_systemd acct="root" exe="/usr/sbin/crond" hostname=? addr=? терміналь=cron res=успіх'
...
Файл містить багато контенту, і він змішаний із багатьма журналами системного аудиту, які не мають нічого спільного з помилками SELinux. Ми використаємо утиліту sealert для допомоги з аналізом (якщо в запиті не вдається знайти команду, встановіть пакет setroubleshoate).
5.2 Аналіз помилок за допомогою sealert
Базове використання команд
sealert -a /var/log/audit/audit.log
Після виконання команди система має витратити час на аналіз порушень у журналах і надати звіт про аналіз. |
Опубліковано 05.07.2019 11:25:50
|
|
|
|
Орендодавець|
Опубліковано 22.07.2021 17:17:58
|
