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.
Далее необходимо задать правила доступа доменов к новому типу, а также правила перехода для этого типа. После этого политика вновь компонуется и загружается при помощи команды make load. Затем новый тип можно применить к файлу, путем обновления конфигурации файловых контекстов и запуска команды 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;
Далее политика может быть перегружена с помощью make load. Администратор должен добавить следующую запись в файл policy/file_contexts/program/init.fc и применить команду restorecon для файла:
dev/initctl system_u:object_r:initctl_t
Процесс создания пользователей, ролей и правил переходов будет рассмотрен на конкретном примере.
2.1.7 Написание новой политики для демона
Мы работаем с обычным демоном под Red Hat Enterprise Linux. Это значит, что есть его инициализирующий скрипт в /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
Загрузите новую политику, используя make load.
Пометьте foo-файлы: restorecon /usr/bin/foo /var/run/foo.pid /etc/foo.conf
Запустите демона, service foo start.
Просмотрите лог аудита в поисках сообщений об отказе:
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 сообщения.
Составьте правило используя эти сообщения и свои знания, пытаясь по возможности использовать макрос.
Загрузите новую политику.
Вернитесь к началу – запустите демона.
Если демон пытается получить доступ к port_t, который связан с tclass=tcp_socket или tclass=udp_socket в логе АВЦ сообщений, вам необходимо определить, какой номер порта foo хочет использовать. Для диагностики (чтобы определить), поместите следующие правила в foo.te:
allow foo_t port_t:tcp_socket name_bind;
auditallow foo_t port_t:tcp_socket name_bind;
Продолжайте в том же духе по оставшимся AVC отказам. Когда они будут разрешены новой политикой, вы можете настроить уникальные требования для foo_t домена.
Запустив демона, определите, какой порт использует foo. Посмотрите на сообщение, разрешенное AVC и увидите, к какому порту подключен демон:
lsof | grep foo.*TCP
foo 2283 root 3u IPv6 3192 TCP *:4242 (LISTEN)
Foo-демон слушает порт 4242
Удалите общее правило port_t, заменив его специальным правилом для нового порта, основанным на домене foo_t.
type foo_port_t, port_type;
allow foo_t foo_port_t:tcp_socket name_bind;
Добавьте эту строку в $SELINUX_SRC/file_contexts. Это зарезервирует порт 4242 для домена foo_t:
ifdef(`foo.te', `portcon tcp 4242 system_u:object_r:foo_port_t')
0 комментариев