“Каждый раз, выполняя команду setenforce 0, Вы заставляете Дэна Уолша плакать.

Дэн отличный парень и, конечно же, не заслуживает этого.”

http://stopdisablingselinux.com/

Есть мнение, что SELinux это машина, главная и единственная задача которой на всякое действие пользователя отвечать «Permission denied». Для многих системных администраторов знакомство с ней начинается с получения первого подобного «непонятного» сообщения об отказе в доступе и заканчивается через 5 минут строкой SELINUX=disabled в /etc/selinux/config.

Как и любой другой серьезный инструмент Security Enhanced Linux наскоком не освоишь. Для того, чтобы научиться с ним эффективно работать, необходимо много практиковаться и вдумчиво читать документацию. Наверно, в этом и заключается главная причина, почему каждое второе руководство в сети по настройке какого-либо сервиса начинается со слов «Отключаем SELinux….». Однако, если на его изучение потратить лучшие годы своей жизни немного времени, станет понятно, что нет так страшен черт, как его малют SELinux прозрачный и интуитивно понятный механизм разграничения доступа. Поэтому, прежде чем бездумно отключать SELinux, давайте разберемся, откуда он вообще взялся, что за люди за ним стоят, как он работает и какой профит от него можно получить. А в качестве бонуса рассмотрим пару примеров и посмотрим, что можно сделать, когда «ваша программа опять не работает» из-за этого SELinux’а.

Не обещаю, что после прочтения статьи Вы станете мастером кунг-фу по написанию политик SELinux, и постигните дзен, настраивая MLS. Однако я надеюсь, что мне удастся Вас заинтересовать и эта статья – лишь первый шаг на пути познания этого, без преувеличения, мощного инструмента.

О целевых политиках, контекстах безопасности, MLS, IAD, TE, NSA и куче других пока что не совсем понятных терминах далее в этой статье. Букв получилось много.

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

Наверняка многие из уважаемых читателей в курсе, что SELinux начинался как проект одной очень могущественной конторы с распиаренным в последние годы СМИ названием National Security Agency (NSA, Агентство национальной Безопасности). Работы над технологией, которая сегодня известна как Security Enhanced Linux (SELinux или Linux с улучшенной безопасностью), начались в начале девяностых годов прошлого века в одном из подразделений NSA, которое носит название Information Assurance Directorate (IAD). Если коротко, основная задача IAD – обеспечение безопасности правительственных информационных систем и других, обрабатывающих секретную информацию или любую другую критичную для военной и разведывательной деятельности. Чтобы эффективно защищать информацию в системах такого уровня, жизненно важно всегда быть хотя бы на полшажочка впереди вероятного противника, постоянно совершенствовать технологии защиты и вести активную научно-исследовательскую деятельность. Для этих целей в составе IAD существует Trusted Systems Research Group  – главный научный центр NSA, в компетенции которого исследование разнообразных проблем, связанных с ИБ, в том числе и разработка архитектур защищенных информационных систем. Именно специалисты этого центра совестно с Secure Computing Corporation, NAI Labs (обе компании — военные подрядчики, купленные в 2002-2003 годах компанией McAfee, ныне подразделение Intel Security Group) и MITRE Corporation (не путать с Mitre Sports International, производителем футбольных товаров :) ) приступили к реализации нескольких научно-исследовательских проектов, призванных заполнить дыры безопасности существующего программного и аппаратного обеспечения. Основная идея всех этих проектов заключалась в создании сильного и гибкого механизма разграничения доступа к информации на уровне ядра ОС.

Первым результатом труда исследователей стала полуисследовательская-полувоенная ОС Distributed Trusted Mach (DTMach), отпрыск проектов Trusted Mach (TMatch) и LOgical Coprocessing Kernel (LOCK). Эти системы разрабатывались в конце 80-ых годов и были призваны обеспечить соответствие требованиям, изложенным в Trusted Computer System Evaluation Criteria, более известного во всем мире как «Оранжевая книга».

За проектом DTMach NSA приступило к реализации масштабной программы под названием «Synergy».

В рамках этой программы для новой архитектуры безопасности были составлены формальные спецификации системы, проведен анализ применяемых и потенциально применимых политик безопасности, а также была исследована возможность использования нового механизма разграничения доступа с различными ОС на базе микроядерной архитектуры. Практический результат исследований вылился в проект Distributed Trusted Operating System (DTOS). Прототип этой ОС был предоставлен различным правительственным организациям и университетам для тестирования и проведения новых исследований.

После закрытия программы «Synergy», NSA, SCC и Университет штата Юта приступили к переносу архитектуры безопасности DTOS в исследовательскую ОС Fluke. Новый проект получил название Flux. Оригинальная архитектура системы безопасности, реализуемая в DTOS, была доработана, что позволило обеспечить улучшенную поддержку динамических политик безопасности. Новая архитектура получила название Flux Advanced Security Kernel (FLASK).

Работы по внедрению FLASK в ядро Linux начались в начале двухтысячных. К этому моменту все наработки по проекту, в т.ч. исходные коды под лицензией GPL, стали доступны opensource-сообществу, а к разработке системы подключились такие компании, как RedHat, Tresys Technology, HP, IBM и другие.

Первая реализация архитектуры FLASK для ядра Linux, получившая название Security Enhanced Linux, предназначалась для версии 2.4.x и была выпущена в виде наборов исправлений (патчей). В 2001 году на конференции «Linux Kernel Summit» NSA выступило с предложением включить SELinux в ядро 2.5.x в том виде, в котором она была реализована на тот момент. Однако Линус Торвальдс, поддерживаемый opensource-сообществом, высказался против такой «захардкоженной» реализации SELinux в ядре, поскольку она исключала возможность использования других схожих по функциональности с SELinux проектов, разработка которых велась параллельно. Вместо принятия подхода «в лоб», было решено использовать некий универсальный интерфейс, который позволяет реализовывать модели безопасности в виде загружаемых модулей.

К концу 2003 года такой фреймворк был разработан. Linux Security Modules (такое название он получил) был включен в mainstream-ветку Linux и стал неотъемлемым компонентом ядра начиная с версии 2.6.x, привнеся вместе с собой возможность использования SELinux, как подключаемого модуля безопасности. К слову, благодаря LSM, не потерялись и альтернативные разработки — AppArmor, Tomoyo и Smack.

На данный момент поддержка SELinux включена в десятки дистрибутивов. И да, эта разработка не обошла стороной и последние версии Android (>=4.3), так что с уверенностью можно сказать, что SELinux обрел заслуженную популярность и оставлять без внимания такую фичу специалисту по ИБ – непозволительная роскошь.

Так что, ребята, серьезно! Прекращайте отключать SELinux!

Почему вдруг дядьки из NSA решили, что «теплых ламповых» юниксовых триплетов недостаточно, чтобы считать систему «безопасной»?

Как известно, «традиционная» модель разграничения доступа в Linux основана на DAC (discretional access control, избирательное (дискреционное или матричное) управление доступом) и в очень редких случаях на ACL (access control lists). В ней, фактически, реализованы только два уровня доступа – суперпользователь (root) и пользователь. Эта модель предполагает, что любая программа, запускаемая пользователем, наследует все его разрешения. Из-за такого поведения процесс получает огромный довесок в виде «лишних» прав. Из-за этой особенности многие системные службы и программы выполняются с явно завышенными полномочиями, и ошибка в любой из этих программ может быть использована для получения несанкционированного доступа к системе. Соблюсти принцип минимизации привилегий с таким подходом очень проблематично.

SELinux как раз тот механизм, который призван гибко ограничивать права пользователей и процессов на уровне ядра ОС, наделяя их только жизненно-необходимыми полномочиями. И если при традиционной модели каждый пользователь, как правило, имеет полную свободу действий над своими файлами, и, в общем-то, ничто, кроме здравого смысла, не помешает ему выполнить что-то типа chmod 777 id_rsa, то при использовании SELinux можно сделать так, чтобы такой трюк не сработал.

Стоит упомянуть, что SELinux дополняет существующие механизмы (политики SELinux всегда проверяются только после проверки традиционных DAC-прав).

При грамотной настройке SELinux способен:

  • снизить риски, возникающие вследствие допущенных ошибок в коде или ошибок конфигурации,
  • эффективно ограничить скомпрометированный процесс, не предоставив злоумышленнику необходимых прав для, допустим, pivoting’а.
  • как минимум запротоколировать несанкционированный доступ, а то и вовсе защитить систему от реальных эксплойтов, используемых «on-the-wild».

Необходимо понимать, что Security Enhanced Linux это не all-in-one решение и он не заменит сильные пароли, межсетевые экраны, антивирусы и не избавит от необходимости регулярно обновлять ПО.

Интересно. И как же эта штука работает?

Для того, чтобы лучше понять, как SELinux работает и что происходит, когда процесс или пользователь обращается к файлу, давайте внимательно взглянем на схему:

Архитектура FLASK в Linux

Первым делом проверяются «традиционные» DAC-права, и если с ними все в порядке, то в бой вступают хуки LSM. Перехватчик событий LSM отлавливает все обращения субъектов к объектам системы и вместе с контекстом безопасности передает их SELinux.

Решение о предоставлении или запрете доступа принимает Policy Enforcement Server (сервер реализации политики безопасности). Для этого он сначала обращается к подсистеме Access Vector Cache (AVC), которая кэширует наиболее часто используемые политики.

Если необходимое решение отсутствует в кэше, то запрос необходимой политики перенаправляется дальше — в базу данных политик безопасности.

Найденная политика безопасности кэшируется в AVC и передается Policy Enforcement Server. Если запрашиваемое действие удовлетворяет требованиям найденной политики, то доступ разрешается. В противном случае сервер реализации политики запрещает доступ, а вся информация записывается в log-файл SELinux (если в политиках явно не указано «dontaudit»).

Помимо принятия решений о предоставлении или запрете доступа, Policy Enforcement Server отвечает также за управление метками безопасности (назначение и удаление).

Ничего сложного. И даже не верится, что к реализации этой архитектуры шли пару десятилетий :).

Метки, метки и… RBAC.

В теории компьютерной безопасности есть такое понятие как Mandatory Access Control (MAC) — принудительное (мандатное) управление доступом. Если не сильно углубляться в теорию и постараться избежать научных и околонаучных терминов, то MAC можно охарактеризовать тем, что всем субъектам и объектам системы сопоставлены метки безопасности. На основании этих меток субъекты системы получают (или не получают) доступ к объектам. Метка субъекта описывает его благонадежность, а метка объекта — степень закрытости содержащейся в нем информации. Субъект – то, что выполняет какие-либо действия над чем-либо (например, пользователи или процессы). Объект – то, над чем выполняются действия (файлы, порты, сокеты, fifo и т.д.).

SELinux — это как раз реализация MAC. Несмотря на то, что для него характерны некоторые черты RBAC (Role-based access control, Управление доступом на основе ролей), ключевое понятие – метки. И всё в SELinux крутится вокруг меток.

В Security Enhanced Linux механизм мандатного управления доступом реализован в виде двух форм, если можно так выразиться:

  • MLS (Multi-Level Security, многоуровневая система безопасности) / MCS (Multi Categories Security, мультикатегорийная безопасность)
  • TE (Type Enforcement, принудительная типизация доступа)

MLS (Multi-Level Security) / MCS (Multi-Category Security)

В этом режиме SELinux базируется на формальной модели Белла-Лападулы. Эта модель основана на двух принципах и ее можно описать следующим словосочетанием: «нет записи вниз, нет чтения вверх» («no write down, no read up»). Субъект с уровнем допуска «Секретно» может получить доступ к объекту с таким же уровнем секретности или ниже. Попытка получения доступа к объекту с меткой «Совершенно секретно» будет отвергнута системой (принцип «no read up»). Субъект также не сможет записать в объект (или создать объект), имеющий уровень допуска ниже своего собственного. Этот принцип носит название «no write down» и его цель состоит в том, чтобы субъект, являясь владельцем какого-либо секрета, случайно (или преднамеренно) не записал его в объект с меткой, допустим, «Для служебного пользования». Эти два принципа реализуют так называемый вертикальный уровень контроля. Кроме того, каждый уровень секретности может быть разбит еще и на категории – горизонтальный уровень. Т.е. совершенно не обязательно, что субъект, имеющий допуск к одной категории на уровне «Секретно», получит допуск ко всем остальным. Если в системе существует только один вертикальный уровень контроля, то в таком случае говорят о мультикатегорийной безопасности (MCS).

Многоуровневая система безопасности и мультикатегорийная безопасность в SELinux

Как можно понять из описания, политика, основанная на MLS, мягко говоря, неприменима к большинству «гражданских» систем. Зачем MLS может понадобиться домашнему пользователю, я вообще ума не приложу. Она требует серьезной проработки на бумаге, а все административные решения о предоставлении или запрете доступа принимает, как правило, одно ответственное лицо – офицер по безопасности (security officer). Несложно догадаться, что основные потребители всего этого добра не веб-серверы в облаках, а военные, государственные и прочие режимные объекты (то есть не зря АНБ и компания корячились над технологией столько лет). И именно поэтому MLS в SELinux максимально точно соответствует «эталонному» определению MAC в TCSEC.

Нет, я не говорю, что MLS не заслуживает внимания обычных пользователей, просто на первых порах достаточно знаний о том, что MLS вообще существует, а знакомство с SELinux лучше начать всё-таки, с основанных на Type Enforcement политиках, которые можно и нужно применять на боевых VPSках в мирное время.

Type Enforcement (TE)

Как говорит нам Wikipedia — TE является первым шагом на пути к MLS. В TE каждый субъект и объект системы, так же, как и в MLS ассоциируется с меткой. Такая метка получила общепринятое название контекст безопасности (context) – строка переменной длины, которая хранится в расширенных атрибутах файловой системы. В контексте безопасности для нас первостепенный интерес представляют два поля – домен (domain) для субъектов и тип (type) для объектов. Домен – это перечень того, что процессы могут делать или какие действия процесс может выполнять над различными объектами. Тип – атрибут объекта, он определяет, кто может получить к нему доступ.

Вместо использования уровней секретности и категорий, как это сделано в MLS, в TE решение о предоставлении или запрете доступа принимается на основании правил (политик), которые определены для каждой пары домен-тип или домен-домен. По своей сути домен и тип равнозначные понятия и единственное отличие в них в том, что наименование домен используется для субъектов, а тип — для объектов.

Небольшое лирическое отступление. Если отталкиваться от «эталонного» определения MAC из Оранжевой книги, Type Enforcement это скорее finegrained (гибкий) DAC. В Type Enforcement базу данных политик безопасности можно сравнить с классической матрицей, используемой в «традиционном» DAC. И главное преимущество TE над классическим DAC не в том, что TE – это «почти что» MAC, а в том, что TE использует гораздо большее количество критериев при управлении доступом. Однако, так как SELinux Wiki считает принудительную типизацию доступа одной из форм MAC, поэтому и мы можем себе позволить считать также. :)

Потихоньку приступаем к знакомству на практике

RedHat, Centos, Fedora, Hardered Gentoo, Hardered Ubuntu, ArchLinux, SUSELinux – все эти дистрибутивы могут предложить поддержку SELinux из коробки. Какой из дистрибутивов выбрать – решать Вам. Я же для экспериментов решил использовать Centos 7.1. Минимальная установка, kernel 3.10.0-229.11.1.el7.x86_64, targeted policy. Думаю, что для человека, интересующегося SELinux’ом не составит особого труда раскатать тот дистрибутив, который ему милее и роднее. Рекомендую дополнительно установить пакеты:

  • policycoreutils-python – базовый набор утилит для работы с SELinux
  • setroubleshoot — инструмент, который анализирует сообщения об отказах AVC, сравнивает их со значениями в своей базе данных, а затем в удобочитаемом виде выводит сообщения об отказе с пояснениями и предлагает возможные варианты решения проблемы.

Для начала поближе познакомимся с контекстом безопасности и выполним команду ls –Z или ls —context в домашнем каталоге пользователя root:

В этом выводе нас будет интересовать строка system_u:object_r:admin_home_t:s0. Эта строка — контекст безопасности, в данном случае, для файла install.log. Контекст предоставляет нам информацию о пользователе (system_u), его роли (object_r), о типе или домене (admin_home_t) и уровне (s0). Для вывода контекста безопасности исполняемых процессов используют утилиту ps c параметрами –eZ.

Рассмотрим каждую составляющую контекста безопасности подробнее.

Пользователь – идентификатор, на основании которого SELinux разрешает или запрещает вхождение в какие-либо роли. Для получения информации о пользователях SELinux, и тем, как они соотносятся с пользователями Linux, воспользуемся утилитой semanage из пакета policycoreutils-python:

В Centos7.1 по умолчанию все пользователи никак не ограничены:

Этот контекст безопасности показывает, что текущий пользователь (в данном случае root) соотнесен с неограниченным SELinux-пользователем unconfined_u, которому соответствуют неограниченные роль unconfined_r и  домен unconfined_t. И хотя пользователь работает неограниченно, приложение, которое он запускает, остаётся ограниченным рамками домена, в котором оно выполняется. Еще одной особенностью является то, что при выполнении команд su или sudo контекст SELinux-пользователя не меняется.

Роль – это атрибут RBAC, «промежуточное звено» между пользователем SELinux и доменами. Он определяет, в какие домены может входить пользователь. Иными словами: роль – это список доменов, которые пользователь имеет право запускать.

Домен (тип) – их мы уже описали ранее.

Уровень – этот атрибут используется в политиках MLS и MCS, поэтому на первых порах, мы будем делать вид, что его не существует. 

Убедимся в том, что SELinux в вашей системе выполняется:

В результате команда вернет текущий режим работы:

Всего их три:

  • Enforcing: SELinux разрешает или запрещает доступ на основании правил политики SELinux. Это как раз тот режим, который можно назвать ON/Enabled. В этот режим мы переводим систему командой setenforce 1 (В этот момент Дэн Уолш торжествует).
  • Permissive: Политики SELinux не применяются. Однако система регистрирует все отказы к предоставлению доступа, как это было бы в режиме Enforcing. Режим используется для отладки. Команда — setenforce 0.
  • Disabled: SELinux отключен. Используются только традиционные правила дискреционной модели разграничения доступа. Отдельной команды для перевода в этот режим не существует. Отключить SELinux можно строкой SELINUX=disabled в /etc/selinux/config или в параметры загрузки ядра дописать selinux=0.

Более подробную информацию о SELinux предоставляет утилита sestatus:

В выводе утилиты мы видим, что SELinux включен, домашний каталог (точка монтирования) SELinux — /selinux Текущий режим – enforcing, режим из конфигурационного файла (применяемый при загрузке) также enforcing. В двух последних строчках информация о применяемых политиках (версия и наименование).

SELinux позволяет использовать различные динамически подгружаемые политики. Как правило, наименование политики отражает ее функциональность. В различных дистрибутивах можно встретить политики под названиями mls, refpolicy, minimum, targeted (как в нашем случае) , strict и другие. Каждая политика основана на одном из режимов MAC (MLS, TE) и RBAC или является комбинацией их свойств.

Написание политик для всех сервисов системы – задача достаточно объемная и едва ли под силу одному отдельно взятому администратору. Поэтому дистрибутивы, поддерживающие SELinux, поставляются с предопределенной политикой. Всю рутинную работу мэинтейнеры и сообщество сделали за нас, нам остается только довериться им и начать использовать SELinux. Если пользователя по какой-либо причине не устраивают имеющиеся политики, или дистрибутив не поддерживает SELinux, всегда можно воспользоваться базовыми политиками (reference policy) от Tresys Technology и доработать их напильником под свои нужды. Но это уже несколько иной уровень мастерства, для начала будем использовать то, что дают.

Для адаптации политик SELinux под конкретную систему можно пойти двумя путями:

  • написать свою, дополненную политику или изменить имеющуюся с последующей сборкой и перекомпиляций. Этот вариант мы не будем рассматривать, т.к. написание политик – достаточно обширная тема и требует отдельной статьи.
  • использовать изменяемые логические значения –переключатели (booleans)

SELinux booleans позволяют изменять части политик «на лету», не обладая при этом глубокими познаниями в написании политик. Для вывода всех доступных переключателей выполним команду:

Для вывода списка booleans с описанием того, за что отвечает каждое значение, воспользуемся командой

По умолчанию, в RHEL-based дистрибутивах используется основанная на TE и RBAC политика targeted (целевая). Название «целевая» эта политика получила потому, что ограничивает только потенциально уязвимые сервисы, при этом доверенные выполняются в неограниченном домене unconfined_t и не управляются политиками SELinux. Обычно говорят, что процесс выполняется в определенном домене или ограничен определенным доменом. Вообще в политике targeted центральными понятиями являются домен или тип. Пользователи и роли могут использоваться в различных политиках, однако в политике targerted  при принятии решений о предоставлении или отказе SELinux почти не использует ни пользователей, ни ролей. Такой подход, конечно, не удовлетворяет требованиям «Оранжевой книги», однако является отличным вариантом «for mere mortals».

Что делать, когда пришла беда и «программа не работает»?

При решении типовых проблем с targeted policy в абсолютном большинстве случаев  проблема обычно решается изменением контекста (типа), конфигурированием переключателей и портов служб.

Итак, для теста будем использовать Centos 7.1 и Zabbix. Я позволю себе не описывать заурядный процесс установки и настройки всего этого дела.

Несмотря на то, что разработчики RHEL предусмотрели кучу вариантов использования их системы с различными сервисами, из коробки Zabbix-сервер как положено не заработал (и это правильное поведение).

selinux_zbx_not_running

 Неопытный админ «решил» бы эту проблему так:

Немного более опытный, воспользуется другим не менее неправильным вариантом и запустит zabbix и httpd в разрешающих доменах (permissive domains):

Когда процесс запущен в разрешающем домене, SELinux не блокирует доступ, но система регистрирует все отказы к предоставлению доступа, как это было бы в режиме Enforcing. Иными словами permissive domain это setenforce 0 для отдельно взятого домена. Если выбирать из двух зол – выключать SELinux полностью, или выключить его только для пары доменов, то второй вариант, конечно, предпочтительнее. Однако и в этом случае кое-кто плачет крокодильими слезами.

Но мы-то с вами знаем, что Дэн отличный парень и  не будем его расстраивать. Что же делать? Как обычно, первым делом смотрим /var/log/audit/audit.log:

По логам видно, что проблема есть, однако новичку по такому сообщению тяжеловато понять, в чем именно она заключается. Т.к. у нас установлен setroubleshootd, более подробные сообщения о запрете доступа логируются также в /var/log/messages:

Чтобы облегчить себе жизнь, рекомендуется воспользоваться утилитой sealert. Она используется для анализа логов и вывода сообщений об ошибках доступа в удобочитаемом виде.

Скормим ей наш audit.log для генерации отчета:

Отчет sealert

[свернуть]

Или скопируем предложенную команду из /var/log/messages:

Отчет sealert

[свернуть]

Неважно, какой вариант вы выберите, в обоих случаях sealert описывает каждую проблему доступа в достаточно подробном виде и предлагает возможные варианты решения. Нам он предложил 3 варианта:

  1. Разрешить подключаться httpd к zabbix’у по 10051 порту. Для этого необходимо изменить значение переключателя httpd_can_connect_zabbix, выполнив команду setsebool -P httpd_can_connect_zabbix 1
  2. Разрешить httpd подключаться по всем портам. Для этого необходимо изменить значение переключателя httpd_can_network_connect, выполнив команду setsebool -P httpd_can_network_connect 1
  3. Sealert предлагает воспользоваться утилитой audit2allow, которая автоматически создаст модуль локальной политики для разрешения действия.

Мы, очевидно, руководствуюсь принципом минимизации привилегий, выберем первый вариант. Изменяет значения переключателей утилита setsebool. Ключ –P позволяет сохранить изменения после перезагрузки (persistent):

Проверяем:

selinux_zbx_runing

 

Bingo! Проблема решена.

Дополнительно хотелось бы обратить внимание на третий вариант. Конечно, audit2allow штука удобная, но я бы не рекомендовал ее использовать никогда. Ни новичкам, ни профессионалам. Проблема в том, что вы не можете досконально знать, что делает ПО, в том числе свое же собственное (ведь от ошибок никто не застрахован, верно?). Другая проблема — представьте, что случится, если в логе AVC был вполне честный отказ для обычного пользователя из домена httpd_t, которому внезапно потребовалось записать в /etc/shadow? Всё верно, и для этого действия AVC создаст разрешающую политику. Поэтому постарайтесь не использовать audit2allow вообще. А если уж решились, действуйте крайне аккуратно.

Рассмотрим еще одну проблемку. Вы решили изменить директорию по умолчанию для БД Zabbix’а. Перенесли необходимые файлы, настроили традиционные 9 бит прав, но… MySQL не стартует:

Опять же первым делом анализируем логи. Для помощи в этом нелегком деле используем утилиту sealert:

Отчет sealert

[свернуть]

Мы видим, что SELinux запретил доступ на чтение и запись к файлу ibdata, т.к. его контекст безопасности имеет неверный тип:

MySQL не может получить доступ к файлам, имеющих тип default_t. Для решения проблемы необходимо изменить тип. Чтобы понять, какой тип нам нужен, воспользуемся возможностями утилиты semanage и выведем список всех контекстов, доступных для MySQL и выберем нужный:

или можно поступить еще проще – посмотреть, какой контекст был у этого файла изначально:

Мы выяснили, что нужен тип mysqld_db_t. Для изменения контекста скопированных файлов опять прибегнем к помощи утилиты semanage. Параметры –a (add) –t (type), как не сложно догадаться, изменяют тип:

Чтобы новый тип применился, необходимо выполнить команду restorecon:

Убеждаемся что новый тип применен:

И старутуем MariaDB:

И опять бинго:

selinux_mysql_started

 

Заключительный пример. Мы изменили порт httpd со стандартного 80 на 1111:

Естественно, SELinux такую самодеятельность не оценил. Алгоритм всё тот же: логи, sealert и спасительная команда:

 

Бинго! Ничего сложного. Если иметь общие представления о том, как SELinux работает, решение подобных проблем не должно вызвать никаких затруднений.

Хорошо, а что же делать, если я столкнулся с проблемой, которая не входит в абсолютное большинство случаев?

  • Вариант раз. Setenforce 0 и присоединиться к плачущему Дэну.
  • Вариант два. Погуглить. Наверняка Вы не одиноки, и кто-то уже написал рабочую политику за Вас или уже сообщил нужным людям, что политика не работает. Если же не смогли ничего найти, то это отличный шанс научиться писать политики самостоятельно ;).

Заключение

Надеюсь, мне удалось рассказать про «непростой» SELinux простыми словами. Материал получился больше обзорно-теоретический, чем практический. Я постарался не превращать его в чтиво, изобилующее научными и полунаучными терминами, а также старался избежать перепечатывания всем известного руководства. Конечно, очень многое осталось за рамками этой статьи и у большинства интересующихся еще остались вопросы или наверняка появились новые.

Однако, я надеюсь, что теперь читатель относится к SELinux, не как к «вундервафле» от вероятного противника и начнет-таки его использовать. Ведь SELinux уже совсем не тот, что был еще 5-10 лет назад — большинство проблем теперь решаются копипастом пары команд.

Ну что, не будете больше расстраивать Дэна Уолша?

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