46596 (607873), страница 3
Текст из файла (страница 3)
Рассмотрим теперь пример перехода домена процесса. Запустите ssh из-под обычного пользователя, или, точнее, из домена user_t (помните, что для проверки текущего контекста безопасности можно использовать команду id). Теперь выполите ps ax --context и найдите строку с данными о команде ssh. Полагая, что это сделал пользователь sasha, она, в частности, увидит:
sasha:user_r:user_ssh_t
Процесс ssh выполняется в домене user_ssh_t потому что программа имеет тип ssh_exec_t, а роль user_r имеет право доступа в домен user_ssh_t.
Все ниже изложенные операции и команды будут рассмотрены для Fedora Core 4 (выбор именно этого дистрибутива будет пояснен чуть ниже, в соответствующей главе).
SELinux входит в стандартную установку данного дистрибутива, поэтому не пришлось делать перекомпиляцию ядра для включения поддержки данной технологии и установки дополнительных модулей и заплаток на ядро. В Приложении 1 приведен краткий алгоритм установки поддержки SELinux в более старых версиях Fedora Core.
2.1.3 Виды политик
В SELinux доступны для использования два вида политик: целевая политика (targeted policy) и строгая политика (strict policy).
Fedora Core 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, и ее вывод будет выглядеть примерно так:
uid=0(root) gid=0(root) groups=0(root),1(bin),2(daemon),3(sys),4(adm),6(disk),10(wheel) context=root:system_r:unconfined_t
Последняя часть контекста безопасности root`а сообщает нам, что оболочка пользователя root запущена в домене unconfined_t, указывающем на использование целевой политики. На системах с примененной строгой политикой контекст SELinux оболочки root`а будет либо root:staff_r:staff_t, либо root:sysadm_r:sysadm_t. Вы также можете выполнить команду id -Z для вывода контекста безопасности без отображения информации о Unix UID/GID (это удобно для сценариев оболочки).
2.1.4 Задачи целевых политик
Целевая политика была разработана, т.к. строгая политика оказалась слишком сложной в использовании многими администраторами. После ее первого представления в составе Fedora Core 2, было получено множество негативных откликов о сложности ее применения. В выпуске Fedora Core 3, по умолчанию, была настроена целевая политика, и нареканий стало значительно меньше. Простой расчет подсказывает, что, по крайней мере, два миллиона людей используют Fedora Core 3, не предполагая, что они используют SELinux. Их системы выполняют то, что требуется, и они не замечают, что демонам запрещено выполнение некоторых операций - подобные действия не выполняются демонами при нормальной работе системы с типовой конфигурацией.
Основная цель разработки политик - это упрощение настройки строгой политики и лучшая настройка для начальной конфигурации, в то время как целевая политика будет наращивать количество "целей" для поддержки большего количества демонов. Можно сказать, что целевая и строка политика сближаются, т.к. строгая политика становится более простой в использовании, а целевая политика - более строгой. Но представляется маловероятным, что когда-либо в ближайшем будущем удастся объединить обе эти политики. Фундаментальная разница между строгой и целевой политиками заключается в том, что строгая политика использует возможности SELinux идентификации и ролей, а целевая - нет.
Некоторые из возможностей целевой политики вытекают из того, что множество демонов работает в домене unconfined_t. Со временем, будем надеяться, что большая часть демонов будет хорошо работать в более ограниченных доменах. Самое большое преимущество, с точки зрения удобства использования, - это отсутствие ограничивающего домена для пользовательских сессий. Поэтому, объединения строгой и целевой политик не произойдет.
2.1.5 Компилирование и загрузка целевой политики
Для изменения существующей целевой политики безопасности можно воспользоваться стандартной программой system-config-securitylevel.
Сервер httpd имеет самое большое количество параметров, т.к. он является гибко настраиваемым и конфигурация политики SELinux должна соответствовать настройке демона.
Возможно, наиболее частым использованием булевых переменных в целевой политике будет выключение защиты SELinux для демонов, которые были настроены так, что они не работают совместно с SELinux. Мы не рекомендуем использовать такие переменные. Они предоставляются в качестве аварийного варианта. Если требования бизнеса заставляют вас запустить демон в конфигурации, где SELinux не может защитить, выключение защиты для конкретного демона предпочтительнее, чем выключение защиты для всей системы целиком.
system-config-securitylevel предполагает просмотр и изменение булевых параметров для ограниченного числа демонов, т.е. дописать политику, используя данную программу, представляется для программиста невозможным.
Из вышесказанного следует, что для изменения политики разработчику придется редактировать исходный код политики, компилировать ее и загружать потом в ядро.
Исходные тексты targeted policy не поставляются вместе с дистрибутивом Fedora Core 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 запускает на исполнение так называемые MakeFile – некоторый аналог командных файлов BAT в Windows)
make install (Устанавливает политику в систему, но не загружает в ядро)
shutdown –r now (Перезагрузка системы. После перезагрузки новая политика будет загружена в систему и внесенную изменения вступят в силу)
Makefile компиляции целевой политики поддерживает следующие параметры:
install – компилирует, устанавливает политику, но не загружает в ядро. Правила установленной политики вступят в силу только после перезагрузки машины.
load - компилирует, устанавливает, и полностью загружает политику в память.
reload - компилирует, устанавливает, и загружает или перезагружает политику. Перезагрузка позволяет загружать политику без перезагрузки компьютера.
policy – только компилирование политики без ее установки в систему. Используется в основном для тестирования при разработке.
relabel - повторно маркирует файловую систему, используя источники политики, расположенные в файле $SELINUX_SRC/file_contexts/file_contexts. Такая операция проделывается при установки SELinux в систему. Данный параметр не рекомендуется к использованию без крайней необходимости.
enableaudit – разрешает журналировать те правила, которые помечены как dontaudit.
После компиляции мы получаем политику в двоичном формате имя которой имеет вид: policy., где 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.
Далее необходимо задать правила доступа доменов к новому типу, а также правила перехода для этого типа. После этого политика вновь компонуется и загружается при помощи команды 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
Процесс создания пользователей, ролей и правил переходов будет рассмотрен на конкретном примере.
![](https://s.studizba.com/z.php?f=/templates/si/i/noavatar.png&w=100&h=100&t=1"){kind=avatar}
