Selinux что это такое
Что такое SELinux? Настройка, включение и отключение
SELinux, или Security Enhanced Linux, — это продвинутый механизм управления доступом, разработанный Агентством национальной безопасности (АНБ) США для предотвращения злонамеренных вторжений. Он реализует мандатную модель управления доступом (MAC — Mandatory Access control) в дополнение к уже существующей в Linux дискреционной модели (DAC — Discretionary Access Control), то есть разрешениям на чтение, запись, выполнение.
У SELinux есть три режима работы:
1. Enforcing — ограничение доступа в соответствии с политикой. Запрещено все, что не разрешено в явном виде. Режим по умолчанию.
2. Permissive — ведёт лог действий, нарушающих политику, которые в режиме enforcing были бы запрещены, но не запрещает сами действия.
3. Disabled — полное отключение SELinux.
Изменение режима SELinux
Файл конфигурации по умолчанию, где можно изменять режим работы — /etc/selinux/config.
Чтобы узнать текущий режим работы, нужно выполнить следующую команду (для работы с SELinux необходимы root-привилегии, поэтому здесь и далее приводятся команды для root-пользователя):
Изменение режима работы на permissive:
и наоборот, на enforcing:
Полностью отключить SELinux можно только через файл конфигурации. Откройте его любым текстовым редактором
и измените параметр SELINUX на disabled:
После чего перезагрузите систему
Политики SELinux
В основе структуры безопасности SELinux лежат политики. Политика — это набор правил, определяющих ограничения и права доступа для всего, что есть в системе. Под “всем” в данном случае понимаются пользователи, роли, процессы и файлы. Политика определяет связь этих категорий друг с другом.
Для понимания политик необходимо понимание базовых терминов. Политика SELinux определяет доступ пользователей к ролям, доступ ролей к доменам и доступ доменов к типам. Разберём значение этих терминов.
Пользователи
В SELinux есть набор предварительно заданных пользователей. Каждая стандартная учётная запись пользователя Linux соответствует одному или нескольким пользователям SELinux.
В Linux пользователи запускают процессы. Это может быть пользователь ivan, открывший документ в редакторе vi (учётная запись ivan запускает процесс vi) или служебная учётная запись, запустившая демон httpd. В SELinux процесс (демон или запущенная программа) называется субъектом.
Роли
Роль определяет, какие пользователи могут осуществлять доступ к заданному процессу. Роли не тождественны группам, они больше похожи на фильтры: пользователь может принадлежать к роли в любое время, если роль это позволяет. Определение роли в политике безопасности SELinux задаёт пользователей, имеющих доступ к этой роли. Роли используются потому, что один из элементов SELinux реализует ролевую модель управления доступом (RBAC — Role Based Access Control).
Субъекты и объекты
Субъект — это процесс, который может потенциально влиять на объект.
Объектом в SELinux называется все, над чем можно выполнять какие-либо действия. Это может быть файл, директория, порт, tcp-сокет, курсор, X-сервер. Действия, которые субъект может выполнить над объектом, являются разрешениями субъекта.
Домены
Домен — это контекст, в котором может работать субъект SELinux (процесс). Этот контекст представляет собой как бы оболочку вокруг субъекта, которая сообщает процессу, что он может и не может делать. Например, домен определяет, какие файлы, директории, ссылки, устройства или порты доступны для субъекта.
Типы
Тип — это контекст для файла, который устанавливает предназначение файла. Например, контекст файла может указывать, что это веб-страница, или что файл находится в директории /etc, или что владелец этого файла — конкретный пользователь. В терминах SELinux контекст файла называется его типом.
Политика SELinux определяет доступ пользователей к ролям, доступ ролей к доменам и доступ доменов к типам. Сначала пользователь должен быть авторизован для получения роли, затем роль должна быть авторизована для доступа к доменам. Домен, в свою очередь, может осуществлять доступ только к определенным типам файлов.
Механизм, при котором процесс, запущенный в определенном домене, может осуществлять только определенные действия над определенными типами объектов, называется принудительным присвоением типов (Type Enforcement — TE).
Работа политики SELinux
Политика SELinux не заменяет традиционную дискреционную модель управления доступом (DAC). Если правило DAC запрещает пользователю доступ к файлу, правила политики SELinux не будут применяться, потому что первая линия обороны уже заблокировала доступ. SELinux начинает работать уже после DAC.
Результат будет выглядеть примерно следующим образом:
Можно заметить, что файлы связаны с различными приложениями:
Следующая команда показывает активную политику:
Изменение переключателей SELinux
Несмотря на то, что прочитать файлы модулей политики невозможно, есть простой способ их настройки. Она осуществляется при помощи булевых переключателей SELinux (boolean).
Чтобы разобраться, как они работают, запустим команду semanage с опцией boolean:
Если у вас будет ошибка
То нужно установить policycoreutils-python
Теперь запускаем semanage с опцией boolean
Будет выведен список различных переключателей, которые можно включить или выключить, краткое описание их функций и текущее состояние:
Первый пункт в этом списке позволяет демону FTP осуществлять доступ к домашним директориям пользователей. В данный момент переключатель выключен (off), то есть доступ запрещен.
Для изменения значений используется команда setsebool. В качестве примера давайте разрешим анонимный доступ FTP на запись. Проверим состояние переключателя командой getsebool:
Она покажет, что в данный момент переключатель выключен:
Изменим значение переключателя и включим его:
Снова проверим состояние переключателя, оно должно поменяться:
Теперь после перезагрузки изменения не потеряются
Заключение
Мы рассмотрели базовые принципы работы SELinux, включение системы и режимы её работы, показали пример обеспечения безопасности системы. Также была разобрана работа политики безопасности и ее настройка при помощи булевых переключателей. Более подробную информацию о SELinux можно найти в соответствующих man-страницах.
Если вы нашли ошибку, пожалуйста, выделите фрагмент текста и нажмите Ctrl+Enter.
Шпаргалка для сисадмина по SELinux: 42 ответа на важные вопросы
Перевод статьи подготовлен специально для студентов курса «Администратор Linux».
Здесь вы получите ответы на важные вопросы о жизни, вселенной и всем таком в Linux с улучшенной безопасностью.
«Важная истина, что вещи не всегда являются тем, чем кажутся, общеизвестна…»
―Дуглас Адамс, Автостопом по Галактике
Безопасность. Повышение надежности. Соответствие. Политика. Четыре Всадника Апокалипсиса сисадмина. В дополнение к нашим ежедневным задачам — мониторингу, резервному копированию, внедрению, настройке, обновлению и т. д. — мы также отвечаем за безопасность наших систем. Даже тех систем, где сторонний провайдер рекомендует нам отключить усиленную безопасность. Это похоже на работу Этана Ханта из “Миссия невыполнима”.
Столкнувшись с этой дилеммой, некоторые системные администраторы решают взять голубую таблетку, потому что они думают, что никогда не узнают ответ на большой вопрос жизни, вселенной и всем таком. И, как мы все знаем, этот ответ 42.
В духе “Автостопом по галактике”, здесь приведены 42 ответа на важные вопросы об управлении и использовании SELinux в ваших системах.
1. SELinux — это система принудительного управления доступом, что означает, что каждый процесс имеет метку (label). Каждый файл, каталог и системный объект так же имеют метки. Правила политики управляют доступом между промаркированными процессами и объектами. Ядро обеспечивает соблюдение этих правил.
2. Двумя наиболее важными концепциями являются: Labeling — маркировка (файлы, процессы, порты и т. д.) и Type enforcement (который изолирует процессы друг от друга на основе типов).
3. Правильный формат метки user:role:type:level (опционально).
4. Целью обеспечения многоуровневой безопасности (Multi-Level Security — MLS) является управление процессами (доменами) на основе уровня безопасности данных, которые они будут использовать. Например, секретный процесс не может прочитать сверхсекретные данные.
5. Обеспечение мультикатегорийной безопасности (Multi-Category Security — MCS) защищает похожие процессы друг от друга (например, виртуальные машины, механизмы OpenShift, песочницы SELinux, контейнеры и т. д.).
6. Параметры ядра для изменения режимов SELinux при загрузке:
# touch /.autorelabel
#reboot
Если системная маркировка содержит большое количество ошибок, вам может потребоваться загрузка в permissive режиме, чтобы перемаркировка прошла успешно.
8. Чтобы проверить, включен ли SELinux: # getenforce
9. Чтобы временно включить/отключить SELinux: # setenforce [1|0]
10. Проверка статуса SELinux: # sestatus
11. Файл конфигурации: /etc/selinux/config
12. Как работает SELinux? Вот пример маркировки для веб-сервера Apache:
14. Существует четыре основных причины ошибок SELinux, которые более подробно описаны в пунктах 15-21 ниже:
19. SELinux нужно знать логические значения включения/выключения настроек SELinux:
21. Ваша информация может быть скомпрометирована, если у вас есть ограниченные домены, пытающиеся:
Перезагрузите или перезапустите auditd после установки.
23. Используйте для вывода списка всех логов, связанных с setroubleshoot :
24. Используйте journalctl для вывода списка всех логов, связанных с определенной меткой SELinux. Например:
25. При возникновении ошибки SELinux используйте лог setroubleshoot с предложением несколько возможных решений.
Например, из journalctl :
26. Логирование: SELinux записывает информацию во многих местах:
28. Для того чтобы найти сообщения SELinux Access Vector Cache (AVC) для определенной службы:
29. Утилита audit2allow собирает информацию из логов запрещенных операций, а затем генерирует правила политики разрешений SELinux. Например:
33. Включение MLS политики SELinux: # yum install selinux-policy-mls
в /etc/selinux/config:
39. Чтобы изменить категории или начать создавать свои собственные, измените файл следующим образом:
/etc/selinux/_ selinuxtype > _/setrans.conf
40. Чтобы запустить команду или скрипт в определенном файле, роли и пользовательском контексте:
Настройка SELinux
В этой статье будет рассмотрена настройка SELinux, мы не будем трогать создание новых политик, а постараемся подойти к системе с другой стороны, посмотреть чем она может быть полезна обычному пользователю Linux, рассмотрим основы её работы, включение, отключение и изменение состояний. В качестве системы для выполнения примеров использовалась CentOS 8.
Основы SELinux
SELinux представляет собой систему маркировки, каждый процесс имеет метку. Каждый файл, каталог или даже пользователь в системе имеет метку. Даже портам и устройствам и именам хостов в системе присвоены метки. SELinux определяет правила доступа процесса к объектам с определенными метками. Это и называется политикой. За соблюдением правил следит ядро. Иногда это еще называется обязательный контроль доступа (Mandatory Access Control, MAC)
Владелец файла не имеет полной свободы действий над атрибутами безопасности. Стандартные атрибуты контроля доступа, такие как группа и владелец ничего не значат для SELinux. Полностью все управляется метками. Значения атрибутов могут быть установлены и без прав root, но на это нужно иметь специальные полномочия SELinux.
разрешить кошке корм_кошек есть
разрешить собаке корм_собак есть
Теперь ядро будет следить, чтобы соблюдались эти правила. В системе SELinux все по умолчанию запрещено, таким образом, если собака попытается съесть кошачий корм, ядро не позволит это сделать.
Допустим, процесс Apache имеет метку httpd_t, а файлы, к которым у Apache должен быть доступ мы назвали httpd_sys_content. Также у нас есть данные кредитных карт, которые хранятся в базе данных mysql. Если хакер взломает процесс Apache и у него будет root доступ, то он все равно не сможет получить доступ к файлам от mysql.
SELinux может вызвать у системных администраторов большое количество проблем, многие её просто отключают, таким образом, решив проблему и уменьшив безопасность. Как уже говорилось выше, по умолчанию SELinux блокирует все и вся. Это подходит под описание строгой политики. Но чтобы облегчить системным администраторам работу, были разработаны другие стандартные политики. Во многих дистрибутивах используется целевая политика (targeted), она охватывает около 200 сетевых служб и процессов, все же остальные программы запускаются и работают свободно, к ним никакие модели SELinux не применяются.
Политики SELinux бывают тоже нескольких типов. Политика targeted, которую мы рассматривали выше относится к типу Type Enforcment (TE) политик, в которых управление доступом к файлам осуществляется на основе ролей. Сюда же относится политика strict. Есть ещё политики Multi-Level Security (MLS), в которых добавлены дополнительные категории, они сложные и ненужны рядовому пользователю, поэтому начинающим можно пока забыть об их существовании. Надо понять, что подсистема SELinux разработана военными для военных, поэтому обычным пользователям все её возможности вряд-ли понадобятся. В этой статье мы будем обсуждать именно политику targeted.
Теория в общих чертах рассмотрена. А теперь перейдем к практической части.
Настройка SELinux
1. Состояние
После перезагрузки вы можете посмотреть посмотреть состояние SELinux:
3. Режим работы
Сейчас давайте включим активный режим, для этого выполните команду:
Отключить активный режим можно передав в ту же команду 0:
Посмотреть используемый сейчас режим тоже можно подобной командой:
Вся основная настройка SELinux выполняется через файл /etc/selinux/config. Здесь можно как полностью отключить selinux, так и настроить используемую политику безопасности.
sudo vi /etc/selinux/config
Этот параметр означает режим работы SELinux, вы можете указать здесь один из трех параметров enforce, permissive и disabled
Используйте disabled чтобы полностью отключить SELinux или любой другой, чтобы включить SELinux обратно. Этот режим будет применяться по умолчанию при старте системы.
4. Выбор политики
Настройка SELinux политик выполняется тоже в этом файле. За политику отвечает параметр SELINUXTYPE:
Вы можете ссылаться на любую политику, расположенную в каталоге /etc/selinux. Могут использоваться три основные политики:
Также можно добавить свои политики. Для применения политики необходимо перезагрузить компьютер, и желательно чтобы SELinux во время этой перезагрузки был в режиме аудита (permissive). Также, чтобы система обновила все метки в файловой системе, возможно, придется создать пустой файл в корне:
5. Просмотр контекста
Каждый файл и каждый процесс имеет свою SELinux метку, которую принято называть контекстом. Какая метка будет присвоена тому или иному файлу или процессу определяется политикой, в нашем случае это targeted. Посмотреть контекст SELinux можно с помощью команды ls:
Синтаксис у строки контекста такой:
имя_пользователя:имя_объекта: тип_или_домен :уровень_доступа
Чтобы посмотреть домен процесса используйте команду ps, например, для httpd:
ps auxZ | grep httpd
Как видите, здесь у сервиса httpd домен httpd_t, это значит что ему будут доступны только те ресурсы, которые разрешено трогать этому домену, в данном случае это тип sys_httpd_content. Все это, включая названия, определено в политике targeted. В то же время другие процессы, здесь, например grep, запущены с доменом unconfined_t, это означает, что им будут доступны все без исключения ресурсы в системе, потому что именно такое поведение настроено в политике для этого домена.
6. Изменение контекста
По умолчанию папка веб-сервера находится по пути /var/www/html. У неё контекст такой, как мы обсудили ранее:
Если вы захотите перенести эту папку в другое место, то надо будет сменить контекст для новой папки. Для этого используется команда chcon, надо указать только тип:
Однако, можно указать контекст полностью:
Это изменение сохранится после перезагрузки, но после обновления меток файловой системы оно будет стёрто. Чтобы этого избежать надо добавить правило в политику.
7. Модификация политики
Вы можете добавить дополнительные правила присвоения меток файлам в политику с помощью утилиты semanage. Чтобы установить тип httpd_sys_content_t для директории /home/losst/httdocs и все файлы в ней надо выполнить:
Если надо поменять контекст только для одного файла, то маску использовать не обязательно:
Сама собой эта команда в файловой системе ничего не меняет надо создать файл /.autolabel и перезагрузить компьютер или выполнить команду restorecon для нужной папки:
Посмотреть все добавленные таким образом правила можно с помощью такой команды:
8. Логи
Несмотря на режим, в котором работает SELinux, все сообщения о нарушениях пишутся в лог файл /var/log/audit/audit.log. Вы можете посмотреть его вручную:
Или для более удобного просмотра можно использовать утилиту sealert. Для её установки выполните:
sudo yum install setroubleshoot
Затем можно смотреть:
Утилита отображает не все строки, а только сообщения об ошибках доступа и при этом выводит предлагаемые решения. Очень удобно. В числе решений утилита предлагает создать свой модуль для политики targeted, который разрешает делать то, что сейчас нельзя.
9. Модули
Политика targeted модульная. Она состоит из множества модулей, для различных программ. Чтобы посмотреть все активные на данный момент модули выполните:
Для просмотра всех установленных модулей выполните:
10. Флаги
Кроме того, поведение политики можно настраивать с помощью флагов. Обычно, флаги, которые надо включить рекомендует та же утилита sealert. Все флаги определены в модулях политики. Посмотреть какие флаги доступны сейчас и их состояние можно с помощью команды:
Чтобы изменить состояние флага используйте команду setsebool. Например, чтобы разрешить модулям httpd подключаться к сети выполните:
Выводы
Теперь вы знаете как включить, отключить SELinux, а также как поменять политику или режим работы программы. Мы рассмотрели работу с контекстом, модулями политики, а также флагами. Этого вполне достаточно чтобы понимать как настроить SELinux на вашем сервере. Все остальное выходит за рамки нашей небольшой статьи.
Прежде чем изучать устройство 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 способен:
Необходимо понимать, что Security Enhanced Linux это не all-in-one решение и он не заменит сильные пароли, межсетевые экраны, антивирусы и не избавит от необходимости регулярно обновлять ПО.
Интересно. И как же эта штука работает?
Для того, чтобы лучше понять, как SELinux работает и что происходит, когда процесс или пользователь обращается к файлу, давайте внимательно взглянем на схему:
Первым делом проверяются «традиционные» 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-Category Security)
В этом режиме SELinux базируется на формальной модели Белла-Лападулы. Эта модель основана на двух принципах и ее можно описать следующим словосочетанием: «нет записи вниз, нет чтения вверх» («no write down, no read up»). Субъект с уровнем допуска «Секретно» может получить доступ к объекту с таким же уровнем секретности или ниже. Попытка получения доступа к объекту с меткой «Совершенно секретно» будет отвергнута системой (принцип «no read up»). Субъект также не сможет записать в объект (или создать объект), имеющий уровень допуска ниже своего собственного. Этот принцип носит название «no write down» и его цель состоит в том, чтобы субъект, являясь владельцем какого-либо секрета, случайно (или преднамеренно) не записал его в объект с меткой, допустим, «Для служебного пользования». Эти два принципа реализуют так называемый вертикальный уровень контроля. Кроме того, каждый уровень секретности может быть разбит еще и на категории – горизонтальный уровень. Т.е. совершенно не обязательно, что субъект, имеющий допуск к одной категории на уровне «Секретно», получит допуск ко всем остальным. Если в системе существует только один вертикальный уровень контроля, то в таком случае говорят о мультикатегорийной безопасности (MCS).
Как можно понять из описания, политика, основанная на 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 это скорее fine—grained (гибкий) 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’ом не составит особого труда раскатать тот дистрибутив, который ему милее и роднее. Рекомендую дополнительно установить пакеты:
Для начала поближе познакомимся с контекстом безопасности и выполним команду 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 в вашей системе выполняется:
В результате команда вернет текущий режим работы:
Более подробную информацию о SELinux предоставляет утилита sestatus:
В выводе утилиты мы видим, что SELinux включен, домашний каталог (точка монтирования) SELinux — /selinux Текущий режим – enforcing, режим из конфигурационного файла (применяемый при загрузке) также enforcing. В двух последних строчках информация о применяемых политиках (версия и наименование).
Написание политик для всех сервисов системы – задача достаточно объемная и едва ли под силу одному отдельно взятому администратору. Поэтому дистрибутивы, поддерживающие SELinux, поставляются с предопределенной политикой. Всю рутинную работу мэинтейнеры и сообщество сделали за нас, нам остается только довериться им и начать использовать SELinux. Если пользователя по какой-либо причине не устраивают имеющиеся политики, или дистрибутив не поддерживает SELinux, всегда можно воспользоваться базовыми политиками (reference policy) от Tresys Technology и доработать их напильником под свои нужды. Но это уже несколько иной уровень мастерства, для начала будем использовать то, что дают.
Для адаптации политик SELinux под конкретную систему можно пойти двумя путями:
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-сервер как положено не заработал (и это правильное поведение).
Неопытный админ «решил» бы эту проблему так:
Немного более опытный, воспользуется другим не менее неправильным вариантом и запустит zabbix и httpd в разрешающих доменах (permissive domains):
Когда процесс запущен в разрешающем домене, SELinux не блокирует доступ, но система регистрирует все отказы к предоставлению доступа, как это было бы в режиме Enforcing. Иными словами permissive domain это setenforce 0 для отдельно взятого домена. Если выбирать из двух зол – выключать SELinux полностью, или выключить его только для пары доменов, то второй вариант, конечно, предпочтительнее. Однако и в этом случае кое-кто плачет крокодильими слезами.
Но мы-то с вами знаем, что Дэн отличный парень и не будем его расстраивать. Что же делать? Как обычно, первым делом смотрим /var/log/audit/audit.log:
По логам видно, что проблема есть, однако новичку по такому сообщению тяжеловато понять, в чем именно она заключается. Т.к. у нас установлен setroubleshootd, более подробные сообщения о запрете доступа логируются также в /var/log/messages:
Чтобы облегчить себе жизнь, рекомендуется воспользоваться утилитой sealert. Она используется для анализа логов и вывода сообщений об ошибках доступа в удобочитаемом виде.