Настройка безопасности SELinux

Makefile компиляции целевой политики поддерживает следующие параметры:

install – компилирует, устанавливает политику, но не загружает в ядро. Правила установленной политики вступят в силу только после перезагрузки машины.

load - компилирует, устанавливает, и полностью загружает политику в память.

reload - компилирует, устанавливает, и загружает или перезагружает политику. Перезагрузка позволяет загружать политику без перезагрузки компьютера.

policy – только компилирование политики без ее установки в систему. Используется в основном для тестирования при разработке.

relabel - повторно маркирует файловую систему, используя источники политики, расположенные в файле $SELINUX_SRC/file_contexts/file_contexts. Такая операция проделывается при установки SELinux в систему. Данный параметр не рекомендуется к использованию без крайней необходимости.

enableaudit – разрешает журналировать те правила, которые помечены как dontaudit.

После компиляции мы получаем политику в двоичном формате имя которой имеет вид: policy.<XY>, где XY – это номер версии политики. Скомпилированная политика будет находиться в корне в папке с исходными файлами.

После загрузки в систему ее можно будет найти по пути /etc/selinux/targeted/policy.

Редактирование целевой политики.

Файлы, содержащие политики для демонов, при использовании целевой политики располагаются в каталоге /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

Процесс создания пользователей, ролей и правил переходов будет рассмотрен на конкретном примере.

Написание новой политики для демона. Мы работаем с обычным демоном под 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')

 

 

 

 

 

 

3. Практическая часть

 

3.1 Выбор дистрибутива Linux

 

Дистрибутив – это определенный набор программ, утилит и документации, объединенный логичной системой установки и сопровождения программных пакетов, ориентированный на определенную группу пользователей и определенный тип задач.

По большому счету, обладая достаточными знаниями, можно накачать из Интернета ядро операционной системы, загрузчик, драйверы, программное обеспечение, и все это установить вручную, а потом долго подгонять и настраивать. Но все же проще взять готовый и настроенный дистрибутив.

На сегодняшний день существуют три базовых дистрибутива и множество их потомков, причем некоторые из них уже имеют крайне мало общего с родителями.

Вот эти три дистрибутива: Debian, Red Hat, Slackware.

Поддержка технология SELinux изначально заложена только в дистрибутивы группы Red Hat, поэтому была выбрана именно она.

Группа Red Hat включает в себя: Red Hat, Fedora Core, KSI, Black Cat, ASP Linux, CentOS, Mandrake, Best Linux, Turbo Linux и др.

Родителем всей этой группы является дистрибутив Red Hat. На сегодня это один из самых популярных дистрибутивов. Компания Red Hat представляет несколько вариантов поставки, но все они платные. Поэтому выбор пал на дистрибутив CentOS – настольную версию Red Hat, отправленную в свободное плавание.

Т.к. поддержка SELinux была включена в дистрибутивы CentOS только с версии 2, а последняя 6-ая версия считается еще не устоявшейся, то был выбран дистрибутив CentOS 5.10.

Для настройки SELinux загрузим CentOS на виртуальной машине.

Рисунок 3.1 – Виртуальная машина с предустановленной CentOS

Рисунок 3.2 – Процесс загрузки CentOS

 

Рисунок 3.3 – Вход в систему

Рисунок 3.4 – Запуск терминала для настройки SELinux

 

3.2 Проверка состояния SELinux

 

Для проверки состояния SELinux существует специальная утилита sestatus. Пример использования (рисунок 3.5):

 

Рисунок 3.5 – Проверка состояния SELinux

Утилита sestatus показывает, что подсистема SELinux включена (SELinux status: enabled), задействован режим ограничений (Current mode: enforcing) и используется политика безопасности под названием targeted.

Все эти параметры устанавливаются в конфигурационном файле /etc/selinux/config. Текущий режим ограничений указывается в параметре SELINUX. Чтобы отключить SELinux, достаточно указать для этого параметра значение disabled.

Как упоминалось ранее, существуют три режима работы SELinux, которые могут быть указаны в соответствующем параметре конфигурационного файла:

Enforcing. Выбор этого значения приводит к применению текущей политики SELinux, при этом будут блокироваться все действия, нарушающие политику. Информация о заблокированных действиях заносится в журнальный файл. Режим Enforcing можно изменить без перезагрузки системы.

Permissive. При указании этого параметра модулем syslogфиксируются попытки выполнения действий, противоречащих текущей политике безопасности, однако фактического блокирования действий не происходит. Режим Permissive, как правило, используется для отладки правил доступа. Смена этого режима на любой другой также не требует перезагрузки.

Disabled. Данное значение в параметре SELINUX файла настроек полностью отключает подсистему обеспечения мандатного контроля доступа. При включении SELinux в любом режиме необходимо заново установить метки безопасности в файловой системе (обычно это делается в процессе перезагрузки системы и может потребовать несколько минут).

В режимах Enforcing и Permissive SELinux сохраняет сообщения в журнальный файл о заблокированных действиях от имени AVC (Access Vector Cache). Однако разница между этими режимами, помимо блокирования и разрешения действий, противоречащих политике безопасности, заключается еще и в том, что в режиме Enforcing, чтобы не перегружать систему избыточными сообщениями, в файл записывается информация только о первом нарушении объектом области разрешений. В режиме Permissive сохраняется запись о каждом из таких нарушений, поэтому в данном режиме удобно проводить отладку политики безопасности.

 

3.3 Переключение между режимами

 

Для переключения между режимами работы Enforcing и Permissive без перезагрузки операционной системы можно использовать утилиту setenforce. Если выполнить команду setenforce enforcing или setenforce 1, то SELinux перейдет в режим Enforcing. Команда setenforce permissive или setenforce 0 переводит в режим Permissive. Такое переключение режимов не влияет на конфигурационный файл SELinux, поэтому после перезагрузки система обеспечения мандатного контроля доступа вернется к режиму, указанному в файле /etc/selinux/config. Также существует команда getenforce, которая выведет краткую информацию, в каком режиме работает SELinux на текущий момент (рисунок 3.6):

 

Рисунок 3.6 – Краткая информация о SELinux

 

Управление режимами работы SELinux можно осуществлять и через параметры ядра Linux. Параметр selinux=0эквивалентен значению Disabled в конфигурации SELinux, а enforcing=0 и enforcing=1 позволят загрузить операционную систему с SELinux, находящимся в режиме Permissive или Enforcing соответственно. Если обнаружится, что SELinux постоянно выключен или загружается в режиме Permissive вне зависимости от значений параметров в конфигурационном файле /etc/selinux/config, то источник проблемы можно поискать в загрузчике. Параметр, задающий такое поведение SELinux, можно найти в файле /boot/grub/grub.conf.

 

3.4 Установка  политик безопасности

 

Помимо режима работы SELinux к основным настройкам подсистемы обеспечения мандатного контроля доступа относится также параметр SELINUXTYPE, указывающий какую политику безопасности необходимо использовать. Учитывая сложность системы, разработчиками SELinux и независимыми специалистами был создан ряд стандартных политик безопасности для системы мандатного контроля доступа. В репозиториях CentOS можно найти четыре пакета, содержащие различные политики безопасности, которые будут подробно рассмотрены ниже: