Selinux что это такое

SELinux — теория

Поэтому я и предпринял попытку кратко и доступно описать что такое SELinux. Доступно для тех, кто еще не сталкивался с системами безопасности. В силу стремления к краткости некоторые аспекты я пропустил, для того чтобы не перегружать — в этой статье только самая суть. В частности я не буду тут описывать что из себя представляет «старая» система безопасности Linux — DAC (discretionary access control, избирательное управление доступом). Или в чем отличия между DAC, MAC и RBAC. Желающие, могут об этом почитать например в википедии.

Что такое SELinux?

SELinux (Security Enhanced Linux) это система безопасности основанная на моделях мандатного и ролевого доступа. Была разработана в начале нулевых (2000-х) годов для того, чтобы исправить недостатки традиционной системы безопасности UNIX (DAC). SELinux реализована как компонент ядра Linux начиная с версии ядра 2.6. То есть SELinux можно использовать в любом дистрибутиве Linux с ядром 2.6 или более поздним. Конечно не во всех дистрибутивах использование SELinux облегчено до максимума, но в принципе можно установить почти в любом.

В нескольких дистрибутивах SELinux устанавливается «из коробки» — это RHEL, CentOS, Fedora. Так, что для реального использования нужно только перевести SELinux в режим enforced. Еще в нескольких дистрибутивах SELinux включен в репозитарий, так что его установка дело нескольких минут — например Debian, Ubuntu. В этих дистрибутивах SELinux устанавливается одной командой «sudo apt-get install selinux» с последующей перезагрузкой.

SELinux и DAC

SELinux работает «после» DAC. То есть операции, запрещенные в DAC не могут быть разрешены в SELinux.
Иными словами SELinux дополняет и конкретизирует действия разрешенные через DAC. При этом SELinux работает независимо от DAC.

Субъекты и объекты

Когда говорят о SELinux всегда упоминаются субъекты и объекты. То есть SELinux это разрешения и запреты которые применяются в действиях между субъектами и объектами.

Субъекты — строго говоря это пользователи, которые выполняют какие-либо операции на компьютере. Однако пользователи всегда действуют через те или иные прикладные программы. То есть человек-пользователь не может сам залезть внутрь компьютера и «своими руками» выполнить например запись в файл. Если ему нужно выполнить запись в файл, он запускает какую-либо программу. Поэтому, под субъектами чаще всего подразумеваются именно программы (процессы). Иначе говоря субъекты это те кто выполняет некие действия.

Объекты это то, над чем действия выполняются. Чаще всего под объектами подразумеваются файлы данных. Но это могут быть и устройства и даже программы. Пример:
cat /var/log/syslog | grep SELinux
в этой команде программа grep объект для программы cat. И соответственно программа cat субъект по отношению к программе grep.

Как включить или выключить SELinux

Включение или выключение SELinux выполняется командой selinuxenabled с параметром 1 (включить SELinux) или 0 (выключить SELinux). Если нужно чтобы SELinux был включен/выключен при запуске системы, тогда редактировать файл /etc/selinux/config (параметр SELinux=disable).

Режимы работы SELinux

Permissive — разрешается нарушение политики безопасности. Такие нарушения только регистрируются в системном журнале. То есть по сути SELinux не работает, а только лишь фиксирует нарушения политики безопасности.

Enforced — нарушения политики безопасности блокируются. SELinux работает полностью.

Переключение режимов работы выполняется командой setenforce с параметром 1 (включить enforced) или 0 (включить permissive). Но если нужно чтобы режим работы устанавливался сразу при загрузке системы, тогда редактировать файл /etc/selinux/config (параметр SELinux=) который может принимать одно из трех значений — permissive, enforced, disable (SELinux отключен).

Команда sestatus позволяется узнать текущий режим работы SELinux.

Журналирование SELinux (аудит)

• настройка auditallow — журналировать события.
• настройка dontaudit — не журналировать события.

• если операция allow, то она журналируется лишь в случае auditallow;
• если операция disallow, то она НЕ журналируется лишь в случае dontaudit.

Контекст безопасности (метка, label) SELinux

Это набор данных состоящий из:

1. типа пользователя
2. роли
3. типа данных или домена процесса
4. уровней и категорий (используется только в специальных политиках MLS/MCS, в общих политиках эти значения установлены в полный доступ)

Контекст безопасности записывается в атрибуты файла (в файловой системе) и создается при установке SELinux (операция labeling). Уже присвоенный контекст безопасности может быть впоследствии изменен — операция transition.

Если файловая система не поддерживает запись меток SELinux (как например NFS), тогда метки записываются отдельно от файлов, при этом связь между файлами и метками происходит по путям файлов. Это может привести к «разрыву» между файлом и его меткой в том случае если файл будет перемещен по другому пути (например каталог с такими файлами будет перемонтирован в другую точку монтирования).

Метка файла может оказаться неверной даже в случае если файловая система поддерживает запись таких меток, но к файлу были неправильно применены операции копирования или перемещения внутри файловой системы. Например при копировании в другую папку файл может получить метку установленную для этой папки (наследование меток), вместо той метки, которая у него была раньше. Поэтому важно правильно выполнять операции копирования и перемещения файлов при использовании SELinux.

Узнать контексты SELinux можно используя стандартные команды с ключом -Z:

• ps -eZ [| gerp имя_программы] : контекст SELinux для работающих программ (или для конкретной программы).
• ls -Z : контекст SELinux для файлов.
• id -Z : контекст SELinux для текущего пользователя.

Пользователь SELinux

Это описательный тип пользователя, а не какой-то конкретный пользователь с логином и паролем. Принципиально это то же самое что и группа пользователей в «старой» системе безопасности DAC. При добавлении, в систему, каждого нового пользователя он по умолчанию (или явным образом) сопоставляется с каким-либо типом пользователя SELinux и в дальнейшем будет иметь те разрешения или запреты, которые указаны для его типа пользователя.

Роль

Перечень разрешенных действий. Возможен переход из одной роли в другую, для изменения полномочий. При этом идентичность пользователя не изменяется (в отличии от команд su/sudo). Роли не совмещаются, они заменяют одна другую.

Политика безопасности определяет допустимые переходы из одной роли в другую. То есть невозможно перейти из любой роли в любую роль. Поскольку роли всегда связаны с типами (доменами), то часто говорят не о смене ролей, а о смене домена (Domain Transition).

Типы (домены) SELinux

Также известны как SELinux sandbox. Объединяют субъекты и объекты в группы, внутри этих групп определяют разрешенные действия субъектов над объектами. Для субъектов вместо термина тип используется термин домен.
Упрощенно можно сказать так:
тип SELinux — для данных;
домен SELinux — для процессов.
В SELinux, в общих политиках, используется механизм принудительного присвоения типов — Type Enforcement. То есть каждый объект и субъект должен быть обязательно приведен к какому-либо типу (или домену).

Политика SELinux (SELinux Policy)

Совокупность всех описанных в системе соотношений пользователь — роль — тип (домен) — уровень и категория. Все типы пользователей, все роли, все типы/домены. Используется два типа политик:

• Type Enforcment (TE) — Roles Based Access Control (RBAC). Targeted и strict — наиболее широко используемые TE — RBAC политики SELinux.
• Bell-La Padula Model Multi-Level Security (MLS) — Multi-Category Security (MCS).

Политика targeted — все процессы не внесенные в специальные ограниченные домены, работают в неограниченном домене unconfined_t. Таким образом осуществляется возможность выполнения процессов которые еще не описаны в политике. Но такие процессы фактически выполняются почти с административными правами. В этом слабое место политики targeted.

Политика strict — все процессы работают в специальных ограниченных доменах, в неограниченном домене unconfined_t никто не работает. Политика strict используется узкоспециально, поскольку требуется ее ручная настройка для каждого конкретного случая. Ведь процессы не описанные в этой политике просто не будут работать. Но зато эта политика обеспечивает полную защиту в рамках тех возможностей которые есть в SELinux.

Политика MLS/MCS

Специальная политика основанная на механизме мандатного доступа. Всем субъектам и объектам присваиваются уровни доступа. В дальнейшем разрешение или запрет на операцию выдается по соотношению уровней доступа у субъекта и объекта. Предмет разрешения только две операции — чтение из файла и запись в файл. Важное отличие этой схемы заключается в том, что разрешения выдаются не на файлы, а на потоки данных связанных с этими файлами.

Правило такое — поток данных не может проходить в направлении понижения уровня доступа. То есть от более высокого уровня к более низкому уровню. Это приводит, на первый взгляд, к нелогичному запрету чтения или доступа в случае если субъект и объект имеют разные уровни доступа. Например субъект с уровнем доступа «секретно» не может писать в файл с уровнем «несекретно». И этот же субъект с правом доступа «секретно» не может читать из файла с уровнем «совершенно секретно», но может писать в этот файл.

Однако, логика тут есть, просто она другая. Если субъект, имеющий уровень «секретно», запишет данные в файл с уровнем «несекретно» то этот файл станет (потенциально) содержать данные уровня «секретно», но при этом будет доступен субъектам уровня «несекретно». То есть станет возможна утечка информации. Поэтому в MLS запись в файлы разрешена только с нижних уровней на верхние.

Эту особенность нужно понимать при присвоении меток уровней доступа.

Помимо уровней, доступ дополнительно регулируется категориями. Субъект не имеющий права доступа к категории «ВМС», не может получить доступ к данным которые имеют метку этой категории. Даже если этот субъект имеет самый высокий уровень доступа.
В контексте SELinux запись об уровнях и категориях выглядит так: «s0-s0:c0.c1023» где «s0-s0» допустимые уровни, а «c0.c1023» допустимые категории. Конкретно такая запись — «s0-s0:c0.c1023» означает высший уровень доступа к любой категории объектов.

Эта часть контекста используется только в специальных политиках MLS/MCS. В общих политиках типа targeted или strict эта часть контекста просто установлена в максимальный уровень разрешений и таким образом не влияет на доступ.

Резюме

Максимальную защиту SELinux дает когда переключен в режим enforced и при этом используется политика strict или политика MLS/MCS.

Если SELinux работает в режиме permissive, то фактически никакой защиты нет — только лишь фиксируются нарушения текущей политики.

Если SELinux переключен в режим enforced, но используется политика targeted, то защита осуществляется только применительно к «известным» программам, для которых в политике определены разрешения и запреты. «Неизвестная» программа фактически имеет административные привилегии.

Если вы живете в г. Краснодар, для вас есть простой способ установить SELinux и научиться им пользоваться. Подробнее.

Иван Сухов, 2012 г.

Поделитесь этим сайтом с друзьями!

Если вам оказалась полезна или просто понравилась эта статья, тогда не стесняйтесь — поддержите материально автора. Это легко сделать закинув денежек на Yoomoney № 410011416229354.

Или на телефон +7(928)274-0281.

Даже небольшая сумма может помочь написанию новых статей 🙂

Или поделитесь ссылкой на эту статью со своими друзьями.

Введение в SELinux под CentOS Stream

Данное руководство – введение в SELinux под CentOS Stream.

Security Enhanced Linux (SELinux) – это система контроля доступа, которая в настоящее время встраиватся в большинство Linux-дистрибутивов. В своё время система была разработана для защиты компьютерных систем от взлома и несанкционированного доступа к ним со стороны злоумышленников. С момента появления SELinux в открытом доступе многие дистрибутивы включили систему в свой код. В этом мануале попробуем протестировать SELinux на сервере под управлением CentOS Stream.

Что такое SELinux?

В операционную систему при помощи SELinux внедряется, так называемая, мандатная модель управления доступом (Mandatory Access Control), сокращённо MAC. Данная модель управления представляет собой способ разграничения контроля доступа с определённым набором привилегий. В дистрибутиве Linux MAC реализована поверх того, что мы называем моделью избирательного управления доступом (Discretionary Access Control), сокращённо DAC.

DAC – это управление доступом на основе списков управления доступом, где объектами доступа служат пользователь, группа и другие. Эти объекты имеют комбинацию полномочий чтение/запись/выполнение или r/w/x. SELinux позволяет ограничить доступ к объектам пользователя, который определён именно им так, что суперпользователь не может иметь суперпривилегии по отношению ко всем объектам нашего пользователя.

Другими словами, SELinux позволяет произвести точную настройку требований контроля доступа, с помощью которой определяется степень влияния пользователя на описанный настройкой процесс. Это в полной мере может предотвратить получение злоумышленником доступа ко всем объектам и процессам системы.

Чтобы понять работу системы, мы произведём настройку конфигурации SELinux на сервере, работающем на операционной системе CentOS Stream.

Установка SELinux

В этом разделе мы установим различные пакеты, используемые в SELinux. Они призваны помочь в создании, управлении и анализе политик SELinux. Сначала необходимо проверить, какие пакеты уже установлены в вашей системе:

# rpm -aq | grep selinux

Если ваша CentOS Stream развёрнута только что, то в системе должны быть установлены следующие пакеты:

Теперь, необходимо запустить установку следующих пакетов и их зависимостей:

# dnf install policycoreutils-python-utils setools setools-console setroubleshoot

Данная инсталляция содержит следующие пакеты:

• policycoreutils-python-utils – содержит инструменты для администрирования SELinux-среды и политик;
• setools – обеспечивает инструменты командной строки возможностью работы с политиками SELinux (в том числе: sediff – инструмент, использующийся для просмотра различий между политиками, seinfo – инструмент для просмотра информации о компонентах, которые создают политики, и sesearch – инструмент для поиска внутри политик);
• setools-console – содержит sediff , seinfo и sesearch ;
• setroubleshoot – набор инструментов, которые помогают определить, что именно (скрипт, файл и т.д.) блокируется системой SELinux.

Состояния SELinux

Установленная на сервер система может находиться во включенном или выключенном состоянии. Сразу после инсталляции на CentOS Stream система будет находиться в состоянии “disabled” (выключено). Для её запуска отредактируйте файл /etc/selinux/config :

# cd /etc/selinux # vi config

В нём значение переменной SELINUX измените с disabled на enabled . После чего перезагрузите сервер:

# reboot

После перезагрузки подключитесь к вашему VPS и проверьте статус SELinux:

# sestatus

Режимы SELinux

Во включенном состоянии SELinux может быть запущен в режимах enforcing и permissive .

В режиме enforcing система SELinux принуждает ОС к применению SELinux-политик и запрещает несанкционированный, с точки зрения SELinux, доступ остальным объектам и процессам. Следующей инструкцией вы можете увидеть загруженные в память системы SELinux-политики:

# semodule -l

В режиме permissive SELinux не блокирует доступ к объектам, не имеющим разрешений от политик SELinux. Вместо этого, система регистрирует любые отказы в доступе, используя /var/log/audit/audit.log .

Проверить, в каком режиме SELinux функционирует сейчас, можно командой:

# getenforce

Переключаться между режимами можно, используя команду setenforce:

# setenforce enforcing

# setenforce permissive

Также, режим permissive можно активировать при помощи инструкции:

# setenforce 0

Активированный режим виден при выводе набора текущих настроек командой sestatus .

Контекст SELinux

SELinux маркирует каждый объект в системе при помощи контекста. Все файлы, пользователи и процессы имеют такую маркировку, которая делится на три части – пользователь, роль и тип. Политика SELinux контролирует роли, получаемые пользователями. Каждая роль несёт в себе ограничения по типам файлов, к которым пользователь имеет доступ. Эти ограничения определены политиками SELinux и содержатся как раз в наборе этих самых меток, который мы и называем контекстом.

Увидеть содержимое контекста для какого-либо каталога можно при помощи команды ls . Для примера, давайте зарегистрируемся в системы под учётной записью пользователя, имеющего привилегии sudo, но не являющимся root’ом. После чего в домашней директории давайте создадим какой-нибудь каталог:

$ mkdir ~/your_dir

А теперь посмотрите, как выглядит контекст этого каталога:

$ ls -Z ~/

Для корневого каталога системы контекст будет выглядеть примерно так:

$ ls -Z /

Мы видим, что содержимое контекста для каждого файла или каталога описано следующим синтаксисом:

user:role:type:level

• user – это имя пользователя;
• role – это имя объекта;
• type – это имя типа для файлов и каталогов, и имя домена для процессов;
• level – это уровень доступа.

А вот, как будет выглядеть в нашей системе контекст для процесса systemd , например:

$ ps Z | grep systemd

Логичекие параметры SELinux

Включение и выключение логических позиций в SELinux может производиться без пересборки политик SELinux.

Во-первых, вы можете увидеть список логических переменных при помощи команды getsebool -a . Для вывода этого списка используйте фильтр grep :

# getsebool -a | grep "httpd_can"

Значение какой-либо переменной изменяется при помощи команды setsebool . Использование опции -P позволяет применять изменения в настройках через перезагрузку. Например, если вы хотите разрешить HTTPD-скриптам подключаться к сети, обновите значение логической переменной следующим образом:

# setsebool -P httpd_can_network_connect ON

Проверить изменения можно при помощи предыдущей инструкции:

# getsebool -a | grep "httpd_can"

В строке httpd_can_network_connect вы должны увидеть значение on :

Заключение

Данное введение в SELinux под CentOS Stream – это ваше первое короткое знакомство с основными понятиями о SELinux: о том, как SELinux может защитить систему, что представляют из себя режимы работы SELinux, как выглядит маркировка объектов и как оперировать логическими параметрами SELinux.

Что такое selinux

Обновлено: 03.12.2021 Опубликовано: 28.12.2016

дополнительная система безопасности для систем на базе Linux. По умолчанию, включена на Red Hat, CentOS, Fedora, Android и др.; на большинство других систем ее можно установить. Использует дополнительные политики для предоставления доступа пользователям и процессам к каталогам и сетевым портам.

Очень часто, администраторы находят данную систему избыточной, поэтому отключают ее. Одной из причин является не самый очевидный процесс ее настройки. Однако, Selinux может существенно увеличить уровень безопасности системы.

Проверить состояние Selinux можно командой getenforce. Возможны следующие варианты:

• Enforcing — включен.
• Permissive — включены только предупреждения.
• Disabled — отключен.

Прочитайте подробнее о Selinux на Википедии

Встречается в статьях

Инструкции:

1. Как установить и настроить связку Asterisk + FreePBX на CentOS 8
2. Установка Bareos на Rocky Linux и настройка резервного копирования
3. Настройка веб-сервера на CentOS 7 со всем необходимым для правильной работы
4. Настройка веб-сервера на CentOS 8 со всем необходимым для правильной работы
5. Настройка кластера Ceph на Linux CentOS 7
6. Использование связки Elasticsearch + Kibana + Logstash на Linux
7. Инструкция по установке и использованию GLPI на Linux CentOS
8. Установка, настройка и использование системы по сбору логов Grafana Loki на Linux
9. Сервер радиовещания на базе Icecast под Windows и Linux
10. Настройка L2TP VPN-сервера на CentOS 8 для возможности подкючения стандартными средствами Windows
11. Как настроить почту для корпоративной среды на CentOS 8
12. Трансляция видео с веб-сервера с помощью NGINX + rtmp
13. Установка XMPP-сервера Openfire на CentOS для мгновенного обмена сообщениями
14. Инструкция по установке и настройке сервера OpenVPN на Linux CentOS 7
15. Как установить и использовать OpenVZ на CentOS
16. Как настроить почту на базе Postfix для корпоративной среды (CentOS 7)
17. Установка и настройка сервера ProFTPd на Linux CentOS 7
18. Установка и настройка системы мониторинга Prometheus на Linux
19. Установка и настройка файлового сервера Samba на CentOS 8
20. Установка и запуск менеджера управления проектами Taiga на Rocky Linux
21. Настройка портала TeamPass для совместного хранения паролей
22. Как установить и настроить панель управления виртуальными машинами VMmanager
23. Установка и настройка FTP-сервера vsFTPd на CentOS 7
24. Установка и настройка почтового сервера Zimbra на Linux

Мини-инструкции:

1. Отключение Selinux в системе Linux
2. Как настроить систему безопасности с SELinux в CentOS
3. Шпаргалка по настройке SELinux для различных программ
4. Способы отключения использования IP версии 6 в Linux CentOS
5. Настройка защиты DNS ответов от BIND при помощи DNSSEC
6. Установка и настройка OwnCloud на CentOS 7 или 8
7. Инструкция по установке и настройке phplist
8. Настройка проксирования почты с NGINX для IMAP, POP3 и SMTP
9. Настройка сервера мониторинга Zabbix на Linux CentOS 7
10. Как настроить мониторинг репликации MySQL/MariaDB с помощью Zabbix
11. Настройка потоковой репликации СУБД PostgreSQL
12. Как наблюдать за репликацией в PostgreSQL с помощью Zabbix
13. Установка и настройка своего локального репозитория CentOS
14. Установка панели управления ISPmanager на Ubuntu или CentOS
15. Как создать свой собственный образ для Docker
16. Отправка логов на удаленный сервер с помощью journald
17. Настройка rsyslog для хранения логов на удаленном сервере Linux
18. Установка и настройка LDAP сервера FreeIPA на Linux CentOS
19. Установка и настройка CRM Битрикс24 на Linux CentOS
20. Настройка мониторинга RAID LSI MegaRaid на Linux с помощью Zabbix
21. Как установить и настроить сервер OpenVPN на Rocky Linux / CentOS 8
22. Установка и использование сервера Freeradius на Linux CentOS 8
23. Настройка сервера видеоконференцсвязи OpenMeetings на Linux CentOS 8
24. Как установить и настроить telegraf + InfluxDB для хранения метрик
25. Установка и настройка сервера NextCloud на Rocky Linux
26. Установка и использование почтового клиента WebMail Lite на Linux CentOS
27. Настройка сервера мониторинга Zabbix 5 на Linux CentOS 8
28. Организация сервиса календаря и адресной книги на базе Baikal
29. Установка и настройка STUN/TURN сервера на базе coturn под Linux CentOS
30. Как установить Jenkins на операционную систему Linux CentOS
31. Установка и запуск в качестве сервера на Linux CentOS приложения Jupyter Notebook
32. Примеры настройки сервисов и их установки с помощью ролей в Ansible
33. Настройка Runner в GitLab CI/CD для загрузки изменений проекта на веб-серверы после коммита
34. Как настроить прозрачную аутентификацию в NGINX через LDAP
35. Установка и настройка сервера Freeradius для проверки подлинности через сервер FreeIPA
36. Шпаргалка по работе с системой управления конфигурациями Ansible
37. Шпаргалка по работе с Dnsmasq — установка и примеры настройки
38. Установка второго сервера FreeIPA с настройкой репликации
39. Как включить и проанализировать подробный лог в СУБД PostgreSQL
40. Как установить Zookeeper на Rocky Linux и настроить кластер из нескольких нод
41. Как создать политику SELinux для приложения или процесса
42. Установка, настройка и создание кластера с помощью keepalived
43. Как настроить кластер PostgreSQL с логической репликацией
44. Как установить и настроить веб-версию pgAdmin на OS Linux

Вопросы и ответы:

45. Принудительный контроль доступа — SElinux

В прошлый раз мы с вами разобрали SSH и затронули тему пользовательских ключей. Мы можем сгенерировать два ключа — приватный и публичный. После чего закинуть публичный ключ на все свои сервера и подключаться к ним без пароля, используя приватный ключ. Это говорит о том, что приватный ключ нужно беречь, как зеницу ока. Давайте глянем права этого файла:

ls -l ~/.ssh 

По ним видно, что к файлу есть доступ только у владельца файла, остальные не могут его прочесть. Вроде бы всё нормально, никакой другой пользователь не сможет украсть этот файл.

А давайте подумаем, что означают права? То, что у процесса, запущенного от имени этого пользователя, будет доступ к этому файлу. И если я запускаю ssh клиент от моего пользователя, то он сможет прочесть этот файл, а если кто-то другой запустит ssh — то это будет процесс от другого пользователя и у него не будет прав к этому файлу. Но что, если я запущу не ssh клиент, а другую программу? Например, firefox. И через firefox попытаюсь прочесть этот файл. С точки зрения стандартных прав всё нормально — это процесс, запущенный от моего пользователя и у него есть доступ ко всем моим файлам. И в обычной ситуации firefox-у не нужны мои ssh ключи. А если он заражён? Что, если я установил какой-то плагин для firefox-а, а он оказался зловредом? Получится, что firefox сможет делать с моими файлами всё что угодно, например, украсть мои ssh ключи. По хорошему, у firefox в принципе не должно быть прав к моим ключам. Но, с точки зрения прав, всё нормально.

А это значит, что стандартных прав недостаточно. У нас есть процессы и файлы, которые могут взаимодействовать с точки зрения прав, но нужно как-то оградить их. И для этого есть системы принудительного доступа. В самом ядре Linux есть фреймворк LSM — что-то типа каркаса, который можно использовать для разработки программ для безопасности. АНБ и RedHat на основе этого каркаса сделали SElinux, который используется многими дистрибутивами на основе RHEL, а на Ubuntu-based дистрибутивах используется AppArmor.

Очень грубо говоря, в SElinux прописаны политики, какой программе что разрешено. Если что-то не прописано — он блокирует это. Политики прописаны на стандартные настройки, а администраторы в программах зачастую меняют эти стандартные настройки. Допустим, мы говорили, что по умолчанию ssh сервер работает на 22 порту, но, если сервер доступен в интернете, стоит изменить стандартный порт. Так вот, если изменить стандартный порт в SSH, SElinux запретит ssh серверу работать на нестандартном порту и демон просто не сможет запуститься. Чтобы он заработал, надо поменять политику в SElinux. И так со многими программами.

Это отпугивает некоторых администраторов, так как нередко они просто копипастят конфиги и команды из интернета, не вникая в то, что там написано. И тут SElinux блокирует демон из-за нестандартных настроек. Администраторы не понимают почему, не знают как решить и ищут одну простую команду — чтобы всё работало. И зачастую эта команда — отключить SElinux. Но отключать безопасность в угоду лени — плохая затея, даже есть специальный сайт, который просит так не делать.

И так, SELinux можно отключать, но не только. В целом у него 3 режима — disabled, permissive и enforcing. Текущий статус можно посмотреть с помощью команд:

sestatus getenforce 

По умолчанию — enforcing — политики работают, всё что не разрешено политиками — блокируется. В режиме permissive ничего не блокируется, но SElinux всё нестандартное логирует. А в режиме disabled он просто отключён.

Режимы можно поменять в файле /etc/selinux/config , изменив значение переменной SELINUX. Но это изменение вступит в силу только после перезагрузки, а чтобы сейчас временно его отключить достаточно прописать setenforce 0:

sudo setenforce 0 getenforce 

что переведёт SElinux в режим permissive. Чтобы заново перевести в enforcing — setenforce 1:

sudo setenforce 1 getenforce 

Выключать SElinux не рекомендую, лучше научиться его настраивать. Но иногда в работе встречается софт, в требованиях которого указано — не работает с SElinux. На самом деле, в большинстве случаев можно проигнорировать это требование и настроить его должным образом. Но если в дальнейшем возникнут проблемы и техническая поддержка софта увидит включённый SElinux — начнёт все проблемы валить на него. Поэтому нужно уметь его выключать, но не стоит это делать просто так. Если всё же нельзя использовать SElinux — используйте режим permissive — логи могут быть полезны.

О деталях работы SElinux поговорим чуть позже, сейчас для понимания нужен пример. Тот же самый SSH с нестандартным портом. Зайдём в конфиг:

sudo nano /etc/ssh/sshd_config 

раскомментируем Port и поменяем значение на другое — Port=2233 . Чтобы изменения вступили в силу, нужно перезапустить демон:

sudo systemctl restart sshd 

Но после команды мы видим ошибку. Если рестарт демона заканчивается ошибкой — значит он перестаёт работать, можем проверить статус:

sudo systemctl status sshd 

Как видите, статус сервиса — activating — это означает, что он пытается запуститься, но не может. Кстати, обратите внимание, что даже при перезапуске SSH сервера и его неработоспособности, я всё ещё подключён по SSH. На самом деле, это скорее исключение из правил, так как большинство других демонов при рестарте сбрасывает соединения. Но SSH так не делает, чтобы администратор не потерял доступ к серверу, так как вернуть доступ может быть довольно сложной задачей.

Первое, что нужно сделать, если сервис не запустился — посмотреть логи:

sudo journalctl -eu sshd 

В большинстве случаев здесь можно найти причину, но в случае с SElinux — в логах демона об этом ни слова. Большинство демонов не в курсе о SElinux и не знают, что их блокирует.

Однако сам SElinux также посылает логи, которые можно увидеть в числе последних:

sudo journalctl -e 

Они сразу выделяются среди остальных логов — здесь и причина блокировки, и подсказка, как решить эту проблему. Здесь мы видим, что SElinux блокирует приложению /usr/bin/sshd использование порта 2233. И тут же подсказка — если вы хотите разрешить, запустите команду — semanage port -a -t тип порта -p tcp 2233 . В типах порта может быть ssh_port_t, vnc_port_t и т.д., но интуитивно понятно, что речь про ssh_port_t.

Попробуем запустить команду:

sudo semanage port -a -t ssh_port_t -p tcp 2233 

После чего рестартнём сервис ssh и проверим его статус:

sudo systemctl restart sshd sudo systemctl status sshd 

Перезапустилось без ошибок и всё работает — внизу видно, что ssh теперь работает на порту 2233.

Это было просто — мы посмотрели последние логи, где SElinux подсказал нам нужную команду, мы её запустили — и всё работает. И в самих настройках SSH, над строчкой смены порта, также указывалась эта команда. Но, справедливости ради, не всегда так просто. В конфигах каких-то часто используемых демонов над часто изменяемыми опциями бывают подсказки, в логах также указываются такие подсказки. Но где-то может не быть подсказок, где-то подсказки могут быть неточными — поэтому нужно немного разобраться в самом SElinux и его командах. Прежде чем продолжим, вернём в конфигах SSH порт 22, так как по 2233 порту мы не сможем подключиться из-за фаервола. После чего рестартнём сервис.

И так, до этого я говорил о том, что SElinux может блокировать доступ к файлу, на примере приватного ключа SSH, а потом показал пример с tcp портом. Также его можно использовать для ограничения доступа к оборудованию, но, в отличии от файлов и сетевых портов, это настраивается реже. Как это работает? Для примера возьмём блокировку доступа к файлу.

Всю работу операционной системы в очень простом виде можно представить так — какой-то пользователь запустил какую-то программу, которая стала процессом, и этот процесс обращается к каким-то файлам. Пользователь, процесс и файл — 3 основных компонента, которым SElinux ставит метки. Эти метки называются контекстами. И SElinux позволяет написать правила, по которому, например, процесс с меткой 2 может читать файл с меткой 3. Когда какой-то процесс пытается открыть файл, сначала система проверяет на стандартные права — группу, владельца, остальных, а также rwx. Если стандартные права говорят, что всё ок, что у процесса есть доступ к файлу, SElinux делает свою проверку — а есть ли у метки 2 доступ к метке 3? И если такого правила нет, то SElinux запрещает это действие и процесс не может открыть файл.

В программы, которые показывают информацию о пользователях, процессах и файлах, для работы с SElinux добавили ключ -Z. Давайте посмотрим контекст нашего пользователя, какого-нибудь процесса и файла:

id -Z ps -Z ls -Z file 

Вот этот страшный набор символов — это и есть контекст. Но пусть вас это не пугает, потому что всё довольно просто.

Обратите внимание, что контекст состоит из нескольких значений, разделённых двоеточием. И в конце каждого значения есть нижнее подчёркивание и определённая буква. u — это юзер, r — это роль, t — это тип.

Начнём с юзера. SElinux не использует системных пользователей, а имеет своих, но при этом их связывает. Это можно увидеть с помощью команды semanage login с ключом -l:

sudo semanage login -l 

В первом столбце — локальные пользователи — __default__ подходит под всех пользователей, root только под рута. Во втором столбце — к какому пользователю SElinux они привязаны — в данном случае и рут, и все остальные наши пользователи привязаны к пользователю unconfined . Т.е. к одному пользователю SElinux привязаны несколько локальных пользователей. Этот пользователь используется, если никаких ограничений по пользователю мы не хотим. Т.е. в нашей системе SElinux никак не ограничивает по пользовательским меткам.

Однако, для максимальной безопасности, если у вас много пользователей в системе, можно настроить SElinux так, чтобы определённые пользователи могли делать только что-то определённое. Например, создать политику, чтобы пользователь не мог запускать sudo. Есть несколько дефолтных пользователей SElinux с прописанными правилами, но, так как в большинстве случаев это только усложнит работу администратору, по умолчанию, у нас не такой жёсткий режим. Т.е. хоть мы и сказали, что в контексте указан юзер, в нашей системе это ничего не значит, у нас нет блокировок по пользовательским меткам.

Но представьте, что ограничения мы будем прописывать по пользователям. Например, пользователю 2 можно настроить только сеть. А если у нас несколько пользователей, которым нужны различные разрешения? Кому-то надо разрешить сеть настраивать, кому-то sudo делать и т.п. Получится, что для каждого пользователя надо отдельные политики писать. А это очень неудобно. Поэтому правила обычно пишутся не на пользователей, а на роли. И у одного пользователя могут быть несколько ролей. Т.е., допустим, у пользователя 2 роль только «сетевой админ», и всё что он может — настроить сеть. А пользователь 1 должен и сеть настроить и пароли задать. Поэтому ему мы даём две роли.

В итоге у нас получается, что несколько обычных пользователей привязываются к одному SElinux пользователю, а у него может быть несколько ролей.

Чтобы посмотреть, у какого пользователя какие роли, можно выполнить команду semanage user с ключом -l:

sudo semanage user -l 

Тут видно, что у некоторых пользователей одна роль, а у некоторых несколько.

И раз уж у нас перед глазами маячит MLS, давайте его тоже упомянем. MLS — многоуровневая безопасность. Это не совсем часть принудительного контроля доступа, скорее отдельный механизм, но тесно связанный с этой темой. Вкратце, MLS позволяет настроить безопасность по уровням. Скажем, у нас есть процесс, у которого определённый уровень. Файлы с уровнями ниже он может читать, файл с тем же уровнем он может читать и изменять, а файл с уровнем выше он может только изменять, не имея доступ для чтения. Но MLS по умолчанию выключен, мы видим его метки, но сейчас никаких ограничений по ним нет.

После роли у нас идёт тип. Если юзер и роль у нас сейчас никак не воздействуют на систему, то именно тип накладывает ограничения. Помните пример в начале, где какой-то процесс не мог открыть файл, потому что метка не позволяла? Так вот, всё дело в типе. У процесса 1 есть свой тип, у файла — свой тип. SElinux проверяет правила, а может ли тип 1 открывать тип 2? Правда типы, относящиеся к процессам, принято называть доменами, а у файлов типы это типы. Т.е. может ли домен 1 открыть тип 2?

Иногда один домен может переходить в другой, например, когда одна программа запускает другую. И это также задаётся в правилах SElinux. Т.е., если одна программа попытается запустить другую, то SElinux проверит, есть ли у программы с доменом 1 право на запуск программы с доменом 2?

И так, принцип работы SElinux-а надеюсь понятен: у каждого пользователя, процесса и файла есть контекст, состоящий из юзера, роли и типа. Юзер и роль определяют разрешения по пользователям, но по умолчанию это вырублено. А типы — если он относится к процессу, то это домен, если к файлу — то это тип — определяют, у каких процессов к каким файлам, другим процессам, портам и устройствам есть доступ, и какой именно. Есть ещё MSL, но он по умолчанию выключен и не совсем по теме.

Давайте попытаемся проанализировать, что мы сделали с SSH, когда меняли порт:

sudo semanage port -a -t ssh_port_t -p tcp 2233 

Сразу виден тип — ssh_port_t . Если посмотреть значение опции -a для semanage-port станет ясно, что мы для этого типа добавили запись. Т.е. теперь ssh_port_t имеет доступ не только к 22 порту, но и к 2233. Это можно увидеть, если посмотреть список всех разрешений по портам:

sudo semanage port -l | grep ssh_port_t 

Ладно, с портами разобрались, что насчёт файлов? За них у нас отвечает semanage fcontext. Например, поищем, какие должны быть контексты у файлов sshd:

sudo semanage fcontext -l | grep sshd 

Тут есть разные файлы, давайте испортим метку одного из файлов, например, /usr/sbin/sshd. Возьмём контекст любого файла:

ls -Z file 

и скопируем. Для смены используем утилиту chcon:

sudo chconf . /usr/bin/sshd 

. После этого попытаемся рестартнуть сервис:

sudo systemctl restart sshd 

Как видите, ssh отказывается запускаться.

Посмотрим логи sshd:

sudo journalctl -eu sshd 

Тут ни слова о причине проблемы. Поэтому просто проверим последние логи:

sudo journalctl -e 

И тут сразу видим подсказку — SElinux запрещает systemd запустить sshd. Скорее всего нет политики, которая бы разрешала домену systemd запускать домен со скопированном типом user_home_t.

Вернём контекст обратно, для этого есть утилита restorecon:

sudo restorecon -v /usr/sbin/sshd 

Она восстанавливает заданный по умолчанию контекст файла. После этого рестарт сервиса прошёл успешно:

sudo systemctl restart sshd 

Так вот, иногда, по определённым причинам, система может восстановить контекст всех файлов в системе. Это можно сделать и вручную, создав пустой файл /.autorelabel в корне и перезагрузившись. Этот процесс занимает определённое время и попросту запускать его не стоит, чтобы случайно ничего не сломать. Поэтому chcon можно использовать как временное решение, иначе случайное восстановление опять всё сломает. И вместо chcon рекомендуется использовать знакомый semanage fcontext.

Например, укажем в политике, чтобы у файла был контекст, как у sshd:

ls -1Z file /usr/sbin/sshd sudo semanage fcontext -at sshd_exec_t /home/user/file 

Обратите внимание, что нужно использовать полный путь к файлу. Если проверить после выполнения команды:

ls -Z file 

казалось бы, ничего не изменилось. Но на самом деле fcontext меняет значение в политике, а не сразу в файле. Поэтому достаточно просто восстановить контекст по умолчанию:

sudo restorecon -v file 

и мы увидим, что тип контекста сменился на sshd_exec_t. Также сможем найти наш файл в политиках:

sudo semanage fcontext -l | grep /home/user/file 

Смена контекста файлов и директорий часто бывает нужна, когда вы меняете стандартные настройки демона. По умолчанию у демона есть право работать с определёнными файлами/директориями, а вам бывает нужно настроить директорию в нестандартном месте. Вы меняете директорию в настройках, а сервис отказывается перезапускаться, потому что не может прочесть файлы, так как контекст не соответствует политике. И для этого есть определённое выражение, рассмотрим на примере Documents:

sudo semanage fcontext -at sshd_exec_t "/home/user/Documents(/.*)?" 

Это меняет контекст в политиках ко всем файлам и поддиректориям. И в конце не забываем восстановить контекст:

sudo restorecon -rv /home/user/Documents 

Тут уже restorecon с ключом -r — рекурсивно.

Иногда бывает, что в рамках безопасности контекст не очень подходит или очень сложно переделать контекст файлов. Поэтому частично возможности SElinux вынесены в двоичные опции — типа разрешить что-то или запретить. Их можно увидеть с помощью semanage boolean или getsebool — например, есть возможность заблокировать плагинам мозиллы доступ к использованию gps:

sudo semanage boolean -l | grep mozilla sudo getsebool -a | grep mozilla_plugin_use_gps 

Как видите, эта опция выключена. Её можно включить используя команду setsebool:

sudo setsebool mozilla_plugin_use_gps on 

В конце можно указать 0, 1 или on, off. И чтобы увидеть изменения используем getsebool:

sudo getsebool -a | grep mozilla_plugin_use_gps 

Но setsebool применяет изменения только в текущей сессии. Чтобы сохранить это значение в политиках, следует использовать ключ -P:

sudo setsebool -P mozilla_plugin_use_gps on sudo semanage boolean -l | grep mozilla 

Ну и напоследок, мы можем все наши изменения вытащить в виде файла с помощью export:

sudo semanage export -f myselinux cat myselinux 

Как видите, тут у нас и изменённый порт, и типы контекста и двоичная опция. Потом мы этот файл можем использовать как шаблон для быстрого применения на наших серверах.

Подведём итоги. Сегодня мы с вами разобрали SElinux — систему, которая играет важную роль в безопасности. Она даёт возможность детальной настройки принудительного контроля доступа. Конечно, мы разобрали только вершину айсберга — поняли, как она работает, как смотреть информацию и решать базовые проблемы. Но для основ этого вполне достаточно. Со временем мы не раз ещё столкнёмся с SElinux-ом и разберём больше примеров и возможностей.

И да, чуть не забыл. В начале я рассказывал про важность ssh ключей и про то, что Firefox не должен иметь к ним доступа. Но при этом спокойно нашёл и открыл ключи, и SElinux ничего не сделал. Просто применять политики от пользовательских программ к пользовательским файлам — невероятно сложно и многое легко сломать. Такие политики будут мешать пользователям и те будут постоянно выключать SElinux. Конечно, при максимальной безопасности это можно настроить, но в обыденной жизни между удобством и безопасностью должен быть компромисс.

© Copyright 2021, GNU Linux Pro, CC-BY-SA-4.0. Ревизия 5f665cc2 .