1. Преамбула
Security-Enhanced Linux (SELinux) — это модуль ядра Linux и подсистема безопасности Linux.
SELinux был в первую очередь разработан АНБ. Ядра 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, фактором, определяющим возможность доступа к ресурсу, является наличие у ресурса прав соответствующего пользователя (чтение, запись, выполнение).
Если процесс, обращающийся к этому ресурсу, соответствует вышеуказанным условиям, к нему можно получить доступ.
Самая фатальная проблема заключается в том, что корневые пользователи не подпадают под какое-либо регулирование, и любые ресурсы системы доступны без ограничений.
Основным элементом этого механизма управления разрешениями является пользователь, также известный как автономный контроль доступа (DAC).
2.3 MAC
В операционной системе, использующей SELinux, факторами, определяющими возможность доступа к ресурсу, являются не только вышеуказанные факторы, но и наличие доступа каждого типа процесса к определённому типу ресурса.
Таким образом, даже если процесс работает как root, необходимо определить тип процесса и типы ресурсов, к которым разрешено обращаться, прежде чем решать, разрешать ли доступ к ресурсу. Активное пространство процесса также может быть сжато до минимума.
Даже сервисный процесс, работающий как root, обычно имеет доступ только к необходимым ресурсам. Даже если программа уязвима, масштаб воздействия ограничен ресурсами, к которым ей разрешено иметь доступ. Безопасность значительно усилена.
Основной частью этого механизма управления разрешениями является процесс, также известный как обязательный контроль доступа (MAC).
MAC подразделяется на два режима: один называется режимом категориальной безопасности (MCS), другой — режимом многоуровневой безопасности (MLS).
Следующие действия находятся в режиме MCS.
2.4 Сравнение DAC и 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, первая перезагрузка после включения может быть медленнее. Потому что система должна создавать безопасный контекст для файлов на диске (я сказал, что перезагрузил игру примерно на 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 корень 7997 0.0 0.0 122784 2156 ? Ss 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.
getsebool -a | 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 для HTTP-сервисов нужно использовать порт 10080.
Semanage порт -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 для помощи в анализе (если подставка не может найти команду, установите пакет setroubleshoot).
5.2 Анализ ошибок с помощью sealert
Базовое использование команд
sealert -a /var/log/audit/audit.log
После выполнения команды системе необходимо потратить время на анализ нарушений в журналах и подготовку отчёта об анализе. |
Опубликовано 05.07.2019 11:25:50
|
|
|
|
Хозяин|
Опубликовано 22.07.2021 17:17:58
|
