2.1.5 Компилирование и загрузка целевой политики
Для изменения существующей целевой политики безопасности можно воспользоваться стандартной программой system-config-securitylevel.
Сервер httpd имеет самое большое количество параметров, т.к. он является гибко настраиваемым и конфигурация политики SELinux должна соответствовать настройке демона.
Возможно, наиболее частым использованием булевых переменных в целевой политике будет выключение защиты SELinux для демонов, которые были настроены так, что они не работают совместно с SELinux. Мы не рекомендуем использовать такие переменные. Они предоставляются в качестве аварийного варианта. Если требования бизнеса заставляют вас запустить демон в конфигурации, где SELinux не может защитить, выключение защиты для конкретного демона предпочтительнее, чем выключение защиты для всей системы целиком.
system-config-securitylevel предполагает просмотр и изменение булевых параметров для ограниченного числа демонов, т.е. дописать политику, используя данную программу, представляется для программиста невозможным.
Из вышесказанного следует, что для изменения политики разработчику придется редактировать исходный код политики, компилировать ее и загружать потом в ядро.
Исходные тексты targetedpolicy не поставляются вместе с дистрибутивом FedoraCore 4, поэтому их придется скачивать и устанавливать из Интернета отдельно. Чаще всего они (тексты) распространяются в RPM-пакетах.
RPM расшифровывается как Red hat linux Package Management или, по-русски, система управления пакетами для операционной системы Red Hat Linux. Говоря проще, RPM представляет из себя файловый формат, предназначенный для автоматизации процедуры инсталляции (а также обновления и удаления) новых программ на машину под управлением Linux: используя специальную утилиту с тем же названием (rpm), можно быстро установить (удалить/обновить) на свой компьютер любую программу, распространяемую в виде RPM-файла. Команды и пример работы с RPM-пакетом можно посмотреть в Приложении 2.
Имя пакета с исходными кодами целевой политики будет иметь вид: selinux-policy-targeted-sources-<номер_версии>.noarch.rpm
После установки исходные коды можно будет найти в директории: /etc/selinux/targeted/src/policy/
Для компиляции политики нужно сделать следующее:
cd /etc/selinux/targeted/src/policy/ (Перейти в директорию с исходными кодами).
make <make_policy_target> (Программа make запускает на исполнение так называемые MakeFile – некоторый аналог командных файлов BAT в Windows)
makeinstall (Устанавливает политику в систему, но не загружает в ядро)
shutdown –rnow (Перезагрузка системы. После перезагрузки новая политика будет загружена в систему и внесенную изменения вступят в силу)
Makefile компиляции целевой политики поддерживает следующие параметры:
install – компилирует, устанавливает политику, но не загружает в ядро. Правила установленной политики вступят в силу только после перезагрузки машины.
load - компилирует, устанавливает, и полностью загружает политику в память.
reload - компилирует, устанавливает, и загружает или перезагружает политику. Перезагрузка позволяет загружать политику без перезагрузки компьютера.
policy – только компилирование политики без ее установки в систему. Используется в основном для тестирования при разработке.
relabel - повторно маркирует файловую систему, используя источники политики, расположенные в файле $SELINUX_SRC/file_contexts/file_contexts. Такая операция проделывается при установки SELinux в систему. Данный параметр не рекомендуется к использованию без крайней необходимости.
enableaudit – разрешает журналировать те правила, которые помечены как dontaudit.
После компиляции мы получаем политику в двоичном формате имя которой имеет вид: policy.<XY>, где XY – это номер версии политики. Скомпилированная политика будет находиться в корне в папке с исходными файлами.
После загрузки в систему ее можно будет найти по пути /etc/selinux/targeted/policy.
2.1.6 Редактирование целевой политики
Файлы, содержащие политики для демонов, при использовании целевой политики располагаются в каталоге /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(/.*)? system_u:object_r:named_zone_t
/var/named/data(/.*)? system_u:object_r:named_cache_t
Первая строка сообщает нам, что каталог /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.
Создание нового домена
Чтобы создать новый домен, администратор сначала должен создать новый файл .te в директории policy/domains и записать в него надлежащие TE правила и объявления. Чтобы задать новому домену набор базовых разрешений, следует использовать следующий макрос: general_domain_access(имя домена)
Создание нового типа
Чтобы создать новый тип, администратор должен сначала добавить его объявление в конфигурацию TE. Если этот тип ассоциирован с конкретным доменом, то его объявление следует поместить в файле .te этого домена. Если же это общий тип, то его объявление может быть помещено в один из файлов директории policy/types.
Далее необходимо задать правила доступа доменов к новому типу, а также правила перехода для этого типа. После этого политика вновь компонуется и загружается при помощи команды makeload. Затем новый тип можно применить к файлу, путем обновления конфигурации файловых контекстов и запуска команды restorecon для этого файла.
В качестве примера возьмем именованный канал /dev/initctl, который используется для взаимодействия с процессом init. Тип initctl_t для этого файла определен в файле policy/domains/program/init.te, как показано ниже:
type initctl_t, file_type, sysadmfile;
Так как этот файл создается во время работы, должно быть создано правило перехода типов, чтобы гарантировать, что он всегда создается с этим типом. Этоправилоприведенониже:
file_type_auto_trans(init_t, device_t, initctl_t)
Два других домена нуждаются в доступе к этому объекту: домен для скриптов /etc/rc.d и домен системного администратора. Отсюда, следующие правила TE разрешений добавлены в файлы политики policy/domains/program/initrc.te и policy/domains/admin.te:
allow initrc_t initctl_t:fifo_file rw_file_perms;
allow sysadm_t initctl_t:fifo_file rw_file_perms;
Далее политика может быть перегружена с помощью makeload. Администратор должен добавить следующую запись в файл policy/file_contexts/program/init.fc и применить команду restorecon для файла:
dev/initctl system_u:object_r:initctl_t
Процесс создания пользователей, ролей и правил переходов будет рассмотрен на конкретном примере.
2.1.7 Написание новой политики для демона
Мы работаем с обычным демоном под RedHatEnterpriseLinux. Это значит, что есть его инициализирующий скрипт в /etc/init.d/ и им можно управлять используя chkconfig. К примеру, эта процедура подразумевает, что вы собираетесь использовать сервисную команду для управления запуском и остановкой демона.
По этой процедуре, вы пишете политику для пакета foo и ассоциированного с ним foo-демона.
Создайтефайл $SELINUX_SRC/domains/program/foo.te.
Поместите макрос вызова демона в файл: daemon_domain(foo)
Создайте файл контекста файлов: $SELINUX_SRC/file_contexts/program/foo.fc.
Поместите первый список контекстов файлов в file.fc. Вам может понадобиться добавить кое-что к нему в дальнейшем, в зависимости от нужд демона
/usr/bin/foo -- system_u:object_r:foo_exec_t
/var/run/foo.pid -- system_u:object_r:foo_var_run_t
/etc/foo.conf -- system_u:object_r:foo_conf_t
Загрузите новую политику, используя makeload.
Пометьте foo-файлы: restorecon /usr/bin/foo /var/run/foo.pid /etc/foo.conf
Запустите демона, servicefoostart.
Просмотрите лог аудита в поисках сообщений об отказе:
grep "avc: denied" /var/log/messages > /tmp/avc_denials
cat /tmp/avc_denials
Посмотрите, что foo_t домен пытается создать сетевой сокет, это udp_socket или tcp_socket, как объект класса в отказе AVC.
avc: denied { create } for pid=7279 exe=/usr/bin/foo \
scontext=root:system_r:foo_t tcontext=root:system_r:foo_t\
tclass=udp_socket
Втакомслучае, добавьтемакрос can_network() в foo.te: can_network(foo_t)
Продолжайте эти действия по базовым шагам, чтобы создать все правила, которые вы хотите. Каждый набор правил, добавленный к политике, может потребовать дополнительных разрешений для foo_t домена.
Запустите демона.
Прочтите AVC сообщения.
Составьте правило используя эти сообщения и свои знания, пытаясь по возможности использовать макрос.