В составе Red Hat Enterprise Linux 4 впервые был представлен Линукс с улучшенной безопасностью (SELinux)
как составная часть продукта с коммерческой поддержкой.
При установке самой новой ОС для предприятий компании Red Hat поддержка SELinux устанавливается и
задействуется по умолчанию. В прошлом SELinux был подвергнут критике из-за отсутствия коммерческой поддержки,
множество больших вычислительных центров не могли использовать его из-за отсутствия поддержки производителя
(Fedorа Core 3 не имеет требуемого уровня поддержки).
Теперь с выходом Red Hat Enterprise Linux 4, SELinux стал поддерживаемой частью операционной системы,
и подобные возражения против использования SELinux потеряли смысл.
Теперь SELinux широко рассматривается как технология, подходящая для больших вычислительных центров.
Целевая политика
Целевая политика является одной из двух типов политик, доступных в SELinux, другая называется - строгая политика.
Red Hat Enterprise Linux 4 не содержит поддержки строгих политик, при этом вы можете использовать этот тип в Fedora Core 3.
Впервые целевая политика была представлена в составе Fedora Core 3.
Ее задача заключается в предоставлении дополнительной защиты некоторым наиболее часто используемым демонам:
ttpd,dhcpd,
mailman,
named,
portmap,
nscd,
ntpd,
portmap,
mysqld,
postgres,
squid,
syslogd,
winbind, и
ypbind
при помощи внедрения Мандатного Управления Доступом (Mandatory Access Control, MAC).
Подобные демоны запускаются в собственном домене, например httpd_t для
httpd и named_t для named.
Другие демоны в системе, для которых не написана специализированная политика, запускаются в домене unconfined_t.
Демоны и системные процессы, работающие в домене unconfined_t, могут использовать только стандартный для Linux
Дискреционный метод управления доступом (Discretionary Access Control, DAC), т.к. SELinux разрешает полный доступ.
При использовании SELinux доступ предоставляется процессам на основе доменов, каждый домен имеет собственный
разрешенный набор операций над файлами, каталогами или другими ресурсами.
Строгая политика принуждает каждую программу работать в ограниченном домене.
Данный подход использовать не так просто, и задача целевой политики увеличить защищенность в наиболее
важных областях, без уменьшения удобства использования.
Для определения работаете ли вы с целевой политикой, проверьте следующее:
Файл /etc/selinux/config должен включать строку
SELINUXTYPE=targeted. Обратите внимание, что таким образом
вы определяете тип политики используемой при загрузке системы. Если вы переходите с одной политики на другую,
задайте переменной SELINUXTYPE значение отличное от используемой
в данный момент политики до выполнения перезагрузки.
Запустите команду id, и ее вывод будет выглядеть примерно так
Последняя часть контекста безопасности root`а сообщает нам, что оболочка пользователя root запущена в
домене unconfined_t, указывающем на использование целевой политики. На системах с примененной строгой политикой
контекст SELinux оболочки root`а будет либо root:staff_r:staff_t, либо root:sysadm_r:sysadm_t.
Вы также можете выполнить команду id -Z для вывода контекста
безопасности без отображения информации о Unix UID/GID (это удобно для сценариев оболочки).
Демоны, для которых написана собственная политика будут по умолчанию запускаться с ее использованием,
но администратор может настроить их для запуска в домене unconfined_t, указав, что они не будут менять домен при запуске.
Например, команда setsebool -P httpd_disable_trans 0 заставит процесс
httpd работать в домене unconfined_t. Каждый демон имеет булевый
параметр, заставляющий его работать в домене unconfined_t. Данный подход может быть использован,
если администратор не может настроить корректную работу в собственном домене
(однако, рекомендуется для лучшей безопасности изменить политику для разрешения работы демона,
вместо запуска в неограниченном домене). Запуск демонов в домене unconfined_t в
такой ситуации снижает безопасность системы и этого, по возможности, стоит избегать.
Изменение булевых параметров может быть осуществлено при помощи утилиты setsebool
или с помощью программы system-config-securitylevel.
При использовании setsebool не забывайте использовать параметр
-P для сохранения значения параметра после перезагрузки.
Для просмотра значений булевых параметров используется утилита getsebool.
Для получения значения одной переменной укажите ее имя в командной строке, например
getsebool httpd_disable_trans. Для просмотра значения всех переменных используйте команду
getsebool -a.
Самый простой пусть изменения значений булевых переменных - использование программы
system-config-securitylevel, как показано на Рисунке 1, Изменение булевых параметров.
Сервер httpd имеет самое большое количество параметров, т.к. он является
гибко настраиваемым и конфигурация политики SELinux должна соответствовать настройке демона.
Возможно, наиболее частым использованием булевых переменных в целевой политике будет выключение
защиты SELinux для демонов, которые были настроены так, что они не работают совместно с SELinux.
Мы не рекомендуем использовать такие переменные. Они предоставляются в качестве аварийного варианта.
Если требования бизнеса заставляют вас запустить демон в конфигурации, где SELinux не может защитить,
выключение защиты для конкретного демона предпочтительнее, чем выключение защиты для всей системы целиком.
Рисунок 1, Изменение булевых параметров
Файлы, содержащие политики для демонов, при использовании целевой политики располагаются в каталоге
/etc/selinux/targeted/src/policy/domains/program/.
Файлы с исходным кодом политик, обычно имеют расширение .te
и соответствуют соглашению об именовании, например syslog.te.
Политики, или .te файлы, содержат правила для соответствующих доменов.
Например, syslogd.te определяет правила работы в домене
syslogd_t, включая такие операции как вывод журналов на консоль,
изменение и создание файлов журналов, журналирование на внешний сервер и так далее.
Файл политики должен соответствовать файлу контекстов, или файлу .fc,
расположенному в /etc/selinux/targeted/src/policy/file_contexts/program/.
Файл контекстов содержит список контекстов безопасности, которые должны быть применены к файлам и каталогам,
используемым демоном. Например, файл named.fc включает в себя:
Первая строка сообщает нам, что каталог /var/named/ имеет тип
named_zone_t. Вторая строка сообщает, что каталог
/var/named/data/ имеет тип named_cache_t.
/usr/sbin/named -- system_u:object_r:named_exec_t
Сообщает нам, что исполняемый файл named имеет тип named_exec_t.
Соглашение об именовании для исполняемых файлов демонов выглядит так:
X_exec_t, где X - это название домена демона.
Этот подход вызывает смену домена с unconfined_t на домен демона
(в нашем примере, named_t) при запуске демона.
При использовании строгой политики для корректной работы демоны должны быть запущены из административной
сессии (роль sysadm_r и домен sysadm_t).
При использовании целевой политики, данное требование не обязательно, т.к. unconfined_t
- это единственный домен для входа пользователей (администратора или обычного пользователя).
Основной файл политики для named - это named.te, который содержит правила
разрешающие доступ к домену named_t и определяет домен и смену домена на него.
Наиболее важная часть в файле named.te:
daemon_domain(named, `, nscd_client_domain')
Она определяет домен named_t и разрешает выполнение основных операций,
таких как запись pid файла в /var/run, запуск порожденных процессов,
журналирование с помощью syslog и так далее. Он также имеет политику для автоматической смены домена
с unconfined_t на named_t при запуске
исполняемого файла с типом named_exec_t.
Задачи целевых политик
Целевая политика была разработана, т.к. строгая политика оказалась слишком сложной в использовании
многими администраторами. После ее первого представления в составе Fedora Core 2, было получено
множество негативных откликов о сложности ее применения. В выпуске Fedora Core 3, по умолчанию,
была настроена целевая политика, и нареканий стало значительно меньше.
Простой расчет подсказывает, что, по крайней мере, два миллиона людей используют Fedora Core 3, не предполагая,
что они используют SELinux. Их системы выполняют то, что требуется, и они не замечают, что демонам запрещено
выполнение некоторых операций - подобные действия не выполняются демонами при нормальной работе системы
с типовой конфигурацией.
Основная цель разработки политик - это упрощение настройки строгой политики и лучшая настройка
для начальной конфигурации, в то время как целевая политика будет наращивать количество "целей"
для поддержки большего количества демонов. Можно сказать, что
целевая и строка политика сближаются, т.к. строгая политика становится более простой в использовании,
а целевая политика - более строгой. Но представляется маловероятным, что когда-либо в ближайшем будущем
удастся объединить обе эти политики. Фундаментальная разница между строгой и целевой политиками
заключается в том, что строгая политика использует возможности SELinux идентификации и ролей, а целевая - нет.
Некоторые из возможностей целевой политики вытекают из того, что множество демонов
работает в домене unconfined_t. Со временем, мы надеемся, что большая часть демонов будет хорошо
работать в более ограниченных доменах. Самое большое преимущество, с точки зрения удобства использования,
- это отсутствие ограничивающего домена для пользовательских сессий. Поэтому, объединения строгой и
целевой политик не произойдет.
Поддерживаемые изменения конфигурации
При использовании целевой политики, значительные изменения нарушат условия поддержки Red Hat Enterprise Linux.
Это включает изменение политик для демонов (в частности, если подобные изменения приводят к уменьшению доступа)
и добавление новых доменов для программ из состава Red Hat Enterprise Linux.
Добавление изменений для программ, которые не входят в состав Red Hat Enterprise Linux может
быть приемлемым, т.к. любые выявленные ошибки функционирования не имеют отношения к рассматриваемому вопросу.
Если вы выходите за рамки поддерживаемой конфигурации либо из-за серьезных изменений в целевой политике
либо, используя строгую политику, поддержка возможностей SELinux будет оказываться в рамках
программы GPS (Red Hat consulting). Для получения поддержки по вопросам не связанным с SELinux,
переведите SELinux в режим выдачи предупреждений (permissive mode) перед тем, как сообщать об ошибке.
Поддержка строгих политик
Выпуск Red Hat Enterprise Linux 4 содержит только пакет целевых политик, т.к. это единственный вариант,
поддерживаемый через Global Support Services.
Пакеты с строгой политикой доступны на сайте Red Hat для организаций, политика которых требует получение
всего ПО из одного источника. Они могут получить набор строгих политик от Red Hat, но они не
будут поддерживается в рамках обычного процесса поддержки. Любой желающий запустить SELinux на системе
Red Hat Enterprise Linux 4 может скачать пакет selinux-policy-strict
(и selinux-policy-strict-sources для внесения изменений в исходный код политики)
и преобразовать систему для использования со строгой политикой.
Для преобразования системы Fedora или Red Hat Enterprise Linux 4 для использования строгой политики
необходимо установить пакет со строгой политикой и запустить утилиту system-config-securitylevel
в графическом X сеансе. Вы увидите закладку для настройки SELinux. На закладке SELinux находится выпадающий список,
позволяющий сделать выбор между установленными политиками, как показано на Рисунке 2, Выбор между установленными политиками.
Рисунок 2, Выбор между установленными политиками.
После того, как вы выбрали одну из политик, вас попросят подтвердить свой выбор,
как показано на Рисунке 3, Подтверждение выбора.
Рисунок 3, Подтверждение выбора.
После выбора данного варианта, вам потребуется перезапустить машину в ближайшее удобное время.
В самом начале процесса загрузки сценарий /etc/rc.sysinit произведет повторную расстановку меток
в файловой системе для нового типа политики. В данный момент конфигурационный файл
/etc/selinux/config имеет одно поле, определяющее тип используемой политики,
указывающее какой вариант будет выбран при следующей загрузке. Тоже поле используется некоторыми
приложениями для определения текущей политики. Т.о. в период между сменой типа политики в
system-config-securitylevel и перезагрузкой, некоторые программы могут
вести себя не так как планировалось из-за того, что их представление об используемой политике не
совпадает с реальностью. Такое поведение не является вопросом безопасности, т.к. эти программы будут
завершаться некорректно, но влияет на удобство использования. Еще одним следствием того, что
текущая политика не совпадает с настройкой для следующей перезагрузки, является то, что
отложенные задания (cron) не будут выполняться.
Процесс повторной расстановки меток в файловой системе заключатся в сравнении полного пути каждого файла
с набором регулярных выражений, и лучшее совпадение указывает на контекст безопасности,
который будет назначен файлу. Поэтому процесс повторной расстановки меток необходим при преобразовании
типа политики с строгой на целевую и обратно. Данный процесс занимает времени не менее,
чем выполнение команды find /, а может занять и вдвое больше времени
вследствие вычисления регулярных выражений. При использовании стандартной установки
Red Hat Enterprise Linux или Fedora на современном оборудовании данный процесс займет несколько минут.
Если вы установили большое число собственных файлов - продолжительность возрастет пропорционально.
В случае, если вы используете сервер с миллионами файлов с одинаковым контекстом безопасности в
пределах собственной файловой системы, в таком случае наилучшим выходом является задание контекста
в команде mount. Это сохранит вам время, затрачиваемое на расстановку
меток, и не займет место на диске для хранения меток безопасности. Например, кэшированные файлы Squid
помечены как system_u:object_r:squid_cache_t.
При большом сервере Squid с файловой системой выделенной под Squid, вы можете поместить текст
fscontext=system_u:object_r:squid_cache_t в поле опций файловой системы
файла /etc/fstab.
Системы Red Hat Enterprise Linux 4, использующие строгую политику будут поддерживаться только при
отключенной функциональности SELinux. Пользователей, выполнивших подобные изменения в системах,
при обращении в поддержку по вопросам, не относящимся к SELinux могут попросить перевести
SELinux в режим предупреждений (permissive mode) и воспроизвести проблему. В режиме предупреждений
SELinux сообщает о том, что операция запрещена, но в действительности блокировка операции не производится.
Режим предупреждений используется при разработке политик SELinux и при других типах тестирования.
Для того, чтобы быстро выявить является ли SELinux источником проблемы, его можно перевести в режим
предупреждений командой setenforce 0 и затем вернуть обратно после
завершения проверки при помощи setenforce 1.
Заметим, что не рекомендуется переводить систему, находящуюся в промышленной эксплуатации, в режим предупреждений.
В данный момент, поддержка строгих политик безопасности осуществляется только GPS
(консалтинговым подразделением Red Hat). Обычный канал поддержки не принимает запросы по этой теме и
гарантии на время реакции здесь не распространяются. Пакеты поддержки строгой политики не входят в комплект дисков
Red Hat Enterprise Linux 4 CD и не официально являются частью дистрибутива.
Каталог /etc/selinux/
В Fedora Core 3 базовый каталог был изменен на /etc/selinux/, и данное
расположение используется в Red Hat Enterprise Linux 4, и будет использоваться в последующих выпусках.
В каталоге /etc/selinux/targeted/ вы найдете файлы целевых политик.
Если вы используете строгую политику, вы увидите каталог /etc/selinux/strict/.
По умолчанию, исходный код политик не устанавливается. Для установки исходного кода политик вам потребуется пакет
selinux-policy-targeted-sources (при использовании строгой политики вам потребуется пакет
selinux-policy-strict-sources). Установка данных пакетов приведет к появлению каталога
/etc/selinux/targeted/src/ (или strict/src/).
Исходные коды политик будут расположены в подкаталоге policy.
Роли пользователей в целевых политиках
При использовании целевой политики в действительности не используются роли пользователей и домены.
Всем пользователям разрешено использовать роль system_r, и поэтому сущности и
роли не используются в управлении доступом SELinux.
При использовании строгой политики каждому пользователю,
который значим для системной политики безопасности (одна из категорий - пользователи,
имеющие административные права), необходима строка в файле users,
в которой указаны те роли, которые ему разрешено принимать.
При целевой политике данный аспект настройки политики не нужен.
Разработка других политик
Дизайн SELinux позволяет хранить все конфигурационные параметры в политике SELinux, и нет параметров, которые
вкомпилированы в исполняемые файлы. Это означает, что настройка SELinux может быть изменена без
изменения программ. Администратор систем Red Hat Enterprise Linux 4 может построить собственную политику,
которая не основана ни на целевой, ни на строгой политике. Еще раз повторим, что это будет выходить за
рамки контракта на поддержку Red Hat Enterprise Linux.
Об авторах
Фай Кокер является приходящим системным администратором. Рассел Кокер работает в Red Hat в области SELinux.
