selinux permissive что это
Шпаргалка для сисадмина по 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 — описание и особенности работы с системой. Часть 2
Коллеги, в первой части статьи о SElinux мы рассмотрели основные особенности работы с системой SELinux. Как и обещано, теперь публикуем вторую часть, в которой основное внимание уделено настройке политик. Что же, приступим.
Индивидуальная настройка политик SELinux
Незначительные изменения в политиках SELinux можно проводить и без полного изменения самой политики. Для этого достаточно модифицировать логические значения, связанные с дополнительными функциями, определенными в политике. Эти функции позволяют, например, предоставлять доступ к домашним каталогам пользователей при помощи Samba или позволять Apache использовать файлы, находящиеся в домашнем каталоге.
По умолчанию, эти функции отключены. Список этих функций заранее предопределен и состоит из наиболее часто используемых задач, встающих перед системным администратором.
Для того, чтобы просмотреть все доступные для вашей системы функции, достаточно выполнить следующую команду:
Для того, чтобы изменить какой-либо параметр, нужно использовать команду setsebool. Например, для того, чтобы разрешить модулям и скриптам сервиса HTTPD подключаться к сети, достаточно ввести в консоли следуещее:
Создание пользовательских политик при помощи audit2allow
Иногда возникают ситуации, когда заранее предопределенных функций не хватает, когда нужно дополнить существующую политику новым модулем, вручную прописав те или иные условия предоставления доступа к чему-либо. Например, мы устанавливаем дополнение Postgrey для нашего почтового сервера, работающего по протоколу SMTP. Наш сервер должен взаимодествовать с Postgrey через Unix-сокеты, но стандартная политика SELinux для почтового сервера не позволяет этого сделать, блокирует попытки взаимодействовать через сокеты.
В подобных ситуациях не поможет изменение контекста файлов, нет дополнительных функций, включив которые, мы могли бы исправить ситуацию. Конечно, всегда можно отключить SELinux для «проблемного» сервиса, но это решение, конечно, далеко не идеально, ведь существует ненулевая вероятность того, что почтовый сервер когда-то будет взломан.
Итак, переведем SELinux в режим Permissive, после чего запустим почтовый сервер. Через некоторое время в журнале SELinux появятся AVC-сообщения, в которых будут зафиксированы все недопустимые действия нашего сервера:
Теперь мы можем использовать утилиту audit2allow для того, чтобы сгенерировать набор правил для локальной политики, разрешающей все необходимые Postgrey действия:
Итак, мы видим, что фильтруется файл audit.log, из которого вычленяются все недопустимые, с точки зрения текущей политики SELinux действия, произоводимые Postgrey. Просмотрев эти действия, мы видим, что SMTP-сервер пытается создать соединение при помощи Unix-сокета, а Postgrey пытается прослушивать этот сокет. Кажется вполне логичным взять эту информацию и создать на ее основе пользовательский модуль для политики SELinux, который разрешил бы эти действия:
Теперь мы должны загрузить этот модуль, дополнив им уже задействованные политики при помощи команды semodule:
После этого мы можем продолжить наблюдение за журналом SELinux, чтобы убедиться в том, что наша только что созданная политика не ограничивает Postgrey. Как только мы будем довольны и уверены в правильной работе политики, мы можем снова активировать режим Enforcing, в полной уверенности, что теперь наш почтовый сервер надежно защищен и, в то же время, полноценно функционирует.
Ручная настройка модулей для политик SELinux.
Adit2allow, без сомнения, отлично справляется с созданием моделей для политик, которые решают какую-то конкретную проблему. Но иногда и эта утилита срабатывает не совсем верно, так что приходится настраивать модуль вручную. Например, рассмотрим записи в AVC-журнале SELinux:
После того, как мы запустим audit2allow и рассмотрим получившуюся в результате политику postfixlocal.te, мы увидим следующее:
Сразу же возникает вопрос, зачем PostDrop пытается получить доступ к /var/log/httpd/error_log? Это не то действие, которое мы могли бы ожидать от этой программы, так что теперь только нам решать позволять это действие или нет.
У нас есть несколько путей решения этой проблемы.
— Мы можем игнорировать эту ошибку и позволить SELinux блокировать доступ к файлу.
— Мы можем позволить это действие, создав соответствующий модуль политики при помощи audit2allow.
— Мы можем вручную отредактировать файл этого модуля, чтобы определить нужную нам реакцию SELinux на попытку доступа к файлу. Например, мы можем запретить аудит этого события, блокируя в тоже время доступ. Для этого мы должны изменить значение «allow» в соответствующей строке на «dontaudit»:
Теперь мы должны вручную скомпилировать и загрузить отредактированный модуль политики:
Таким образом доступ к файлу /var/log/httpd/error_log блокируется, но мы не получаем постоянных предупреждений об этом от SELinux.
Собственно, по SELinux пока все, а в последующих статьях мы рассмотрим такую интересную (и, надеемся, полезную) тему, как дисковые квоты в linux для rpm-дистрибутивов. Новая статья будет опубликована уже в понедельник.
SELinux – описание и особенности работы с системой. Часть 1
О SELinux на Хабре уже писали, однако, не так много опубликовано подробных мануалов по данной системе. Сегодня мы публикуем именно такой, подробный мануал по SELinux, начиная от информации по системе, и заканчивая гибкой настройкой политик.
Для того, чтобы не превращать пост в «простыню», сложную для понимания, мы решили разделить мануал на две части. Первая будет рассказывать о самой системе, и некоторых ее особенностях. Вторая – о настройке политик. Сейчас публикуем первую часть, чуть позже будет опубликована и вторая часть.
1. Введение
SELinux (SELinux) — это система принудительного контроля доступа, реализованная на уровне ядра. Впервые эта система появилась в четвертой версии CentOS, а в 5 и 6 версии реализация была существенно дополнена и улучшена. Эти улучшения позволили SELinux стать универсальной системой, способной эффективно решать массу актуальных задач. Стоит помнить, что классическая система прав Unix применяется первой, и управление перейдет к SELinux только в том случае, если эта первичная проверка будет успешно пройдена.
1.1 Некоторые актуальные задачи.
Для того, чтобы понять, в чем состоит практическая ценность SELinux, рассмотрим несколько примеров, когда стандартная система контроля доступа недостаточна. Если SELinux отключен, то вам доступна только классическая дискреционная система контроля доступа, которая включает в себя DAC (избирательное управление доступом) или ACL(списки контроля доступа). То есть речь идет о манипулировании правами на запись, чтение и исполнение на уровне пользователей и групп пользователей, чего в некоторых случаях может быть совершенно недостаточно. Например:
— Администратор не может в полной мере контролировать действия пользователя. Например, пользователь вполне способен дать всем остальным пользователям права на чтение собственных конфиденциальных файлов, таких как ключи SSH.
— Процессы могут изменять настройки безопасности. Например, файлы, содержащие в себе почту пользователя должны быть доступны для чтения только одному конкретному пользователю, но почтовый клиент вполне может изменить права доступа так, что эти файлы будут доступны для чтения всем.
— Процессы наследуют права пользователя, который их запустил. Например, зараженная трояном версия браузера Firefox в состоянии читать SSH-ключи пользователя, хотя не имеет для того никаких оснований.
По сути, в традиционной модели избирательного управления доступом (DAC), хорошо реализованы только два уровня доступа — пользователь и суперпользователь. Нет простого метода, который позволил бы устанавливать для каждого пользователя необходимый минимум привилегий.
Конечно, есть множество методов обхода этих проблем в рамках классической модели безопасности, но ни один из них не является универсальным.
1.1.1 Основные термины, использующиеся в SELinux:
Домен — список действий, которые может выполнять процесс. Обычно в качестве домена определяется минимально-возможный набор действий, при помощи которых процесс способен функционировать. Таким образом, если процесс дискредитирован, злоумышленнику не удастся нанести большого вреда.
Роль — список доменов, которые могут быть применены. Если какого-то домена нет в списке доменов какой-то роли, то действия из этого домена не могут быть применены.
Тип — набор действий, которые допустимы по отношения к объекту. Тип отличается от домена тем, что он может применяться к пайпам, каталогам и файлам, в то время как домен применяется к процессам.
Контекст безопасности — все атрибуты SELinux — роли, типы и домены.
1.2 Решение проблем традиционной модели безопасности.
SELinux следует модели минимально необходимых привилегий для каждого сервиса, пользователя и программы намного более строго. По умолчанию установлен «запретительный режим», когда каждый элемент системы имеет только те права, которые жизненно необходимы ему для функционирования. Если же пользователь, программа или сервис пытаются изменить файл или получить доступ к ресурсу, который явно не необходим для решения их, то им будет просто отказано в доступе, а такая попытка будет зарегистрирована в журнале.
SELinux реализована на уровне ядра, так что прикладные приложения могут совсем ничего не знать о версии этой системы принудительного контроля доступа, особенностях её работы и т.д. В случае грамотной настройки, SELinux никак не повлияет на функционирование сторонних программ и сервисов. Хотя, если приложение способно перехватывать сообщения об ошибках этой системы контроля доступа, удобство пользования таки приложением существенно возрастает. Ведь в случае попытки доступа к защищенному ресурсу или файлу, SELinux передает в основное приложение ошибку из семейства «access denied». Но лишь немногие приложения используют получаемые от SELinux коды возврата системных вызовов.
Вот несколько примеров использования SELinux, которые позволяют увидеть, каким образом можно увеличить степень безопасности всей системы.
— Создание и настройка списка программ, которые могут читать ssh-ключи.
— Предотвращение несанкционированного доступа к данным через mail-клиент.
— Настройка браузера таким образом, чтобы он мог читать в домашней папки пользователя только необходимые для функционирования файлы и папки.
2. Режимы работы SELinux
SELinux имеет три основных режим работы, при этом по умолчанию установлен режим Enforcing. Это довольно жесткий режим, и в случае необходимости он может быть изменен на более удобный для конечного пользователя.
Enforcing: Режим по-умолчанию. При выборе этого режима все действия, которые каким-то образом нарушают текущую политику безопасности, будут блокироваться, а попытка нарушения будет зафиксирована в журнале.
Permissive: В случае использования этого режима, информация о всех действиях, которые нарушают текущую политику безопасности, будут зафиксированы в журнале, но сами действия не будут заблокированы.
Disabled: Полное отключение системы принудительного контроля доступа.
Вы можете посмотреть текущий режим и другие настройки SELinux (а в случае необходимости и изменить его) при помощи специального GUI-инструмента, доступного в меню «Администрирование» (system-config-selinux). Если же вы привыкли работать в консоли, то можете посмотреть текущий статус командой sestatus.
Также вы можете узнать статус SELinux при помощи команды getenforce.
Команда «setenforce» позволяет быстро переключаться между режимами Enforcing и Permissive, изменения вступают в силу без перезагрузки. Но если вы включаете или отключаете SELinux, требуется перезагрузка, ведь нужно заново устанавливать метки безопасности в файловой системе.
Для того, чтобы выбрать режим по-умолчанию, который будет применяться при каждой загрузке системы, задайте значение строки ‘SELINUX=’ в файле /etc/selinux/config, задав один из режимов — ‘enforcing’, ‘permissive’ или ‘disabled’. Например: ‘SELINUX=permissive’.
3. Политики SELinux
Как отмечалось ранее, SELinux по-умолчанию работает в режиме Enforcing, когда любые действия, кроме разрешенных, автоматически блокируются, каждая программа, пользователь или сервис обладают только теми привилегиями, которые необходимы им для функционирования, но не более того. Это довольно жесткая политика, которая обладает как плюсами — наибольший уровень информационной безопасности, так и минусами — конфигурирование системы в таком режиме сопряжено с большими трудозатратами системных администраторов, к тому же, велик риск того, что пользователи столкнутся с ограничением доступа, если захотят использовать систему хоть сколько-нибудь нетривиальным образом. Такой подход допустим в Enterprise-секторе, но неприемлем на компьютерах конечных пользователей. Многие администраторы просто отключают SELinux на рабочих станциях, чтобы не сталкиваться с подобными проблемами.
Для того, чтобы избежать этого, для ключевых приложений и сервисов, таких как, например, httpd, named, dhcpd, mysqld, определены заранее сконфигурированные целевые политики, которые не позволят получить злоумышленнику доступ к важным данным. Те же приложения, для которых политика не определена, выполняются в домене unconfined_t и не защищаются SELinux. Таким образом, правильно выбранные целевые политики позволяют добиться приемлемого уровня безопасности, не создав при этом для пользователя лишних проблем.
4. Контроль доступа в SELinux
SELinux предоставляет следующие модели управления доступом:
Type Enforcement (TE): основной механизм контроля доступа, используемый в целевых политиках. Позволяет детально, на самом низком уровне управлять разрешениями. Самый гибкий, но и самый трудоемкий для системного администратора механизм.
Role-Based Access Control (RBAC): в этой модели права доступа реализуются в качестве ролей. Ролью называется разрешения на выполнение определенных действий одним или несколькими элементами системы над другими частями системы. По-сути, RBAC является дальнейшим развитием TE.
Multi-Level Security (MLS): многоуровневая модель безопасности, в которой всем объектам системы присваивается определенный уровень доступа. Разрешение или запрет доступа определяется только соотношением этих уровней.
Все процессы и файлы в рамках SELinux имеют контекст безопасности.
Давайте посмотрим на контекст на практике, подробно рассмотрев стартовую страницу веб-сервера Apache, находящуюся по адресу /var/www/html/index.html
В дополнение к стандартным правам доступа к файлу, мы можем видеть контекст безопасности SELinux: system_u: object_r: httpd_sys_content_t.
Контекст базируется на user:role:type:mls, но поля user:role:type отображаются, в то время как поле mls скрыто. Также мы можем видеть целевую политику, в данном случае httpd_sys_content_t.
Теперь рассмотрим контекст безопасности SELinux для процесса ‘httpd’ (веб-сервер Apache):
Как мы видим, этот процесс запущен на домене httpd_t.
Ну а теперь давайте посмотрим на контекст безопасности файла в нашем домашнем каталоге:
Мы видим, что файл имеет тип user_home_t, этот тип присваивается по умолчанию всем файлам в домашнем каталоге.
Доступ разрешен только между элементами с одинаковым типом, именно поэтому веб-сервер Apache может без проблем читать файл /var/www/html/index.html, который имеет тип httpd_sys_content_t. В то же самое время, так как Apache запущен на домене httpd_t и не имеет заполненных полей userid:username, он не может получить доступ к файлу home/username/myfile.txt, хотя этот файл доступен для чтения процессам, для которых не определена целевая политика. Таким образом, если веб-сервер Apache будет взломан, то злоумышленник не сможет получить доступ к файлам или запускать процессы, которые не находятся в домене httpd_t.
5. Устранение проблем SELinux
Рано или поздно происходит ситуация, когда вы сталкиваетесь с ситуацией, когда SELinux запрещает вам доступ к чему-то. Есть несколько основных причин отказа доступа:
— Неправильно маркированный файл.
— Процесс работает в неправильном контексте
— Ошибка в политике. Процесс требует доступ к файлу, который не был учтен при создании политики.
— Попытка вторжения.
5.1 Изменение меток контекста безопасности файлов.
Команда «chcon» позволяет изменяет контекст SELinux для файлов или каталогов точно таким же образом, как команды «chown» и «chmod» позволяют менять владельца файла или права доступа к нему в рамках стандартной системы контроля доступа.
Рассмотрим несколько примеров.
Предположим, что в системе установлен веб-сервер Apache и нам необходимо изменить папку, в которой хранятся сайты (по-умолчанию это /var/www/html/) на, допустим, /html/ и создать в этом каталоге файл index.html.
Выше мы видим, что и каталог /html, и файл /html/index.html в рамках контекста безопасности имеют тип default_t. Это означает, что если мы запустим Apache и попробуем начать работать с этим каталогом или файлом, то SELinux откажет нам в доступе. И это будет абсолютно правильно, ведь правильный контекст безопасности для файлов, взаимодействующих с Apache, это httpd_sys_content_t.
Изменим контекст и проверим правильно ли все сделано:
Подобные изменения контекста безопасности будут сохраняться между перезагрузками, однако, при изменении меток файловых систем, изменения пропадут. В процессе обслуживания и эксплуатации, подобное не редкость. Правильным решением в такой ситуации будет (после тестирования, конечно) создать дополнительное правило, после чего объеденить его с местными локальными правилами. Таким образом, оно будет иметь более высокий приоритет, чем базовые правила.
Для того, чтобы SELinux корректно работал даже после изменения меток файловых систем, мы можем использовать как инструменты для управления SELinux c GUI-интерфейсом, так и консольную утилиту semanage:
В примере выше мы присвоили контекст httpd_sys_content_t всем файлам, находящимся в катологе /html.
5.2 Восстановление контекста безопасности SELinux.
Команда «restorecon» позволяет изменить контекст безопасности на тот, который был присвоен по-умолчанию.
Снова используем в качестве примера веб-сервер Apache. Предположим, что пользователь отредактировал в своем домашнем каталоге копию файла index.html и переместил (командой mv) его в каталог, в котором храняться сайты (/var/www/html).
Следует обратить внимание, что при копировании (команда cp) контекст безопасности файла будет совпадать с контекстом каталога назначения, при перемещении же, контекст безопасности будет совпадать с контекстом источника. Конечно, мы могли бы использовать команду chcon для изменения контекста безопасности, но так как перемещенные файлы находятся сейчас в каталоге /var/www/html, мы можем просто восстановить параметры контекста для всех файлов, находящихся в этом каталоге.
Для того, чтобы восстановить контекст только для файла index.html, мы можем применить команду:
Если же мы хотим рекурсивно обойти весь каталог и изменить контекст для всех содержащихся в нем файлов, используем следующую команду:
5.3 Изменение меток для всей файловой системы.
Иногда бывает необходимо заново устанавливать метки безопасности во всей файловой системе. Чаще всего такую операцию производят при повторном включении SELinux, после того, как система была на некоторое время отключена. Также это бывает нужно, если мы меняем тип управления политиками на strict (в этом случае все процессы работают в своих специальных доменах, в домене unconfined_t не может работать никто).
Для того, чтобы автоматически переразметить файловую систему при следующей перезагрузке, введите следующие команды:
Иногда автоматическая переразметка не срабатывает (чаще всего в тех случаях, когда дистрибутив с выключенной системой SELinux был обновлен). В таком случае воспользуйтесь следующей командой:
5.4 Предоставление доступа к портам.
Нередко мы хотим, чтобы сервисы, подобные Apache, имели возможность прослушивать нестандартные порты и принимать на них входящие соединения. Базовые политики SELinux позволяют получить доступ только к заранее предопределенным портам, которые жестко связаны с тем или иным сервисом. Допустим, мы хотим, чтобы Apache прослушивал 81 порт. В таком случае, нам надо добавить правило при помощи команды semanage:
Полный список портов, к которым SELinux предоставляет доступ, можно просмотреть следующим образом:
В следующей, второй части мануала, мы покажем возможность гибкой настройки политик системы.