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

 

Роль (role). Роль определяет, какие домены могут быть использованы. Домены, к которым имеет доступ пользовательская роль, предопределяются в конфигурационных файлах политики. Если роль не имеет доступа к заданному домену (в базе данных политики), то при попытке выполнить это действие доступ будет запрещён.

Роли представляют собой наборы привилегий. В любой момент времени каждый пользователь может выступать в одной из доступных ему ролей. Роли позволяют предоставлять пользователю дополнительные привилегии, не утрачивая его идентичности, как это происходит при применении команды su в традиционных системах Unix/Linux. Политика безопасности SELinux может налагать ограничения не только на количество ролей, доступных процессу, но и определять правила перехода из одной роли в другую. Не всякий переход из одной роли в другую допустим.

Очевидно, что роли гораздо чаще используются субъектами, чем объектами, а некоторые объекты (скажем, дисковые файлы), вообще не нуждаются в ролях. Таким объектам присваиваются «пустые роли», не влияющие на безопасность.

Пример:

для того, чтобы разрешить пользователю из домена user_t (домен непривилегированных пользователей) выполнять команду passwd, в соответствующем файле конфигурации указано:

role user_r types user_passwd_t

Она означает, что пользователь с ролью user_r может входить в домен user_passwd_t, т.е. может выполнять команду passwd.

 

Контексты безопасности. Права субъектов и объектов определяются в SELinux контекстами безопасности, состоящими из идентификатора, роли и типа объекта. Идентификатор субъекта — это идентификатор пользователя SELinux, создавшего процесс-субъект. Идентификатором объекта является идентификатор пользователя-владельца объекта (обычно это пользователь, создавший объект).

Каждый субъект и объект идентифицируется собственным контекстом безопасности, которому соответствует идентификатор безопасности SID, причем система контекстов сильно отличается от традиционной системы учетных записей в ОС Linux поэтому возникает задача их взаимодействия. В соответствии с принципом независимости SELinux поддерживает таблицу контекстов безопасности, независимую от таблицы учетных записей Linux. При этом возможно отображение нескольких учетных записей Linux на одну учетную запись SELinux. Таким образом, изменения в учетных записях Linux не влияют на параметры безопасности SELinux.

Модель безопасности SELinux требует, чтобы каждый файл в системе был связан с определенным контекстом безопасности, поэтому в ходе установки всегда выполняется маркировка (labeling) объектов файловой системы. В соответствии с принципом независимости маркировка файлов не влияет на маски доступа к файлам, а в соответствии с принципом приоритета традиционной системы безопасности запреты, наложенные маской доступа, отменяют разрешения SELinux.

Контекст безопасности это набор всех атрибутов, связанных с объектами типа файлов, каталогов, процессов, TCP сокетов и т.п. Контекст безопасности состоит из сущности, роли и домена или типа. Увидеть свой собственный контекст вы можете, выполнив команду id в SE Linux.

Важно понимать различие между доменом и типом.

У процессов есть домен. Когда вы смотрите контекст безопасности процесса (пример команды приведен в следующем разделе), последнее поле -- это домен, например user_passwd_t (если выполняется программа passwd).

Такие объекты как файлы, каталоги, сокеты и т.п. имеют типы. Например, при выполнении команды ls --context для файла, последнее поле представляет тип, такой как user_home_t для файлов, созданных в домашнем каталоге пользователя с ролью user_r.

Вот здесь и накапливается непонимание, где есть домен, а где тип. Рассмотрим файловую систему /proc. У каждого процесса есть домен, а в файловой системе /proc для каждого процесса есть каталог. Каждый процесс имеет метку, или точнее, контекст безопасности, в применении к файлу. Но в файловой системе /proc, метка содержит тип, а не домен. Не смотря на то, что /proc представляет собой выполняющиеся процессы, содержимое /proc является файлами, а потому имеет тип, а не домен.

Вызов команды ls --context /proc выдаёт следующую информацию для процесса init (процесс с идентификатором 1):

dr-xr-xr-x root root system_u:system_r:init_t 1

Метка, или контекст безопасности, говорит нам о том, что этот файл имеет тип init_t. Но, кроме того, это значит, что процесс init выполняется в домене init_t. Каждый файл и каталог файловой системы /proc, соответствующий некоторому процессу, также следует этому соглашению, т.е. тип, указанный в выводе команды ls --context соответствует, так же, домену в котором выполняется процесс.

Ещё одним важным моментом является то, что команды chsid (изменить идентификатор безопасности) и chcon (изменить контекст) не работают на файловой системе /proc, т.к. она не поддерживает изменение меток.

Контекст безопасности файла, например, может варьироваться в зависимости от домена, который создал файл. По умолчанию, новый файл или каталог наследует тип от родительского каталога, однако вы можете задать иную политику.

Пример:

пользователь sasha создаёт файл test в своем домашнем каталоге. После чего выполняет команду ls --context test и видит:

-rw-r--r-- sasha sasha sasha:object_r:user_home_t test

Теперь sasha создаёт файл в каталоге /tmp с именем tmptest и выполняет команду ls --context /tmp/tmptest. Теперь результат такой :

-rw-r--r-- sasha sasha sasha:object_r:user_tmp_t /tmp/tmptest

В первом примере контекст безопасности включал тип "user_home_t", который является типом по умолчанию для домашнего каталога непривилегированного пользователя с ролью user_r. После выполнения второй команды ls --context, видим, что тип теперь user_tmp_t. Это тип по умолчанию для файлов, созданных процессами домена user_t в каталоге типа tmp_t.

 

 

Переход (transition). Решение о переходе, определяет контекст безопасности, который будет назначен запрошенной операции. Есть два основных типа переходов. Первый тип, это переход домена процесса. Он используется при выполнении процесса определённого типа. Второй, это переход типа файла, который применяется при создании файла в определённых каталогах.

Пример:

Пример перехода второго типа (переход типа файла) приведён в предыдущем разделе "контекст безопасности". При выполнении команды ls --context вы можете видеть тип файла (т.е. user_home_t и user_tmp_t в вышеприведённом примере). Итак, при создании пользователем файла в каталоге /tmp происходит переход в тип user_tmp_t и новый файл помечается соответствующим образом.

Рассмотрим теперь пример перехода домена процесса. Запустите 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.

 

Виды политик.

В 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 (это удобно для сценариев оболочки).

Задачи целевых политик.

Целевая политика была разработана, т.к. строгая политика оказалась слишком сложной в использовании многими администраторами. После ее первого представления в составе Fedora Core 2, было получено множество негативных откликов о сложности ее применения. В выпуске Fedora Core 3, по умолчанию, была настроена целевая политика, и нареканий стало значительно меньше. Простой расчет подсказывает, что, по крайней мере, два миллиона людей используют Fedora Core 3, не предполагая, что они используют SELinux. Их системы выполняют то, что требуется, и они не замечают, что демонам запрещено выполнение некоторых операций - подобные действия не выполняются демонами при нормальной работе системы с типовой конфигурацией.

Основная цель разработки политик - это упрощение настройки строгой политики и лучшая настройка для начальной конфигурации, в то время как целевая политика будет наращивать количество "целей" для поддержки большего количества демонов. Можно сказать, что целевая и строка политика сближаются, т.к. строгая политика становится более простой в использовании, а целевая политика - более строгой. Но представляется маловероятным, что когда-либо в ближайшем будущем удастся объединить обе эти политики. Фундаментальная разница между строгой и целевой политиками заключается в том, что строгая политика использует возможности SELinux идентификации и ролей, а целевая - нет.

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

Компилирование и загрузка целевой политики.

Для изменения существующей целевой политики безопасности можно воспользоваться стандартной программой system-config-securitylevel.

Сервер httpd имеет самое большое количество параметров, т.к. он является гибко настраиваемым и конфигурация политики SELinux должна соответствовать настройке демона.

 

 

 

 

 

 

 

 

 

 

Рисунок 1.1 – Настройка демона

Возможно, наиболее частым использованием булевых переменных в целевой политике будет выключение защиты 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_policy_target> (Программа  make запускает на исполнение так называемые MakeFile – некоторый аналог командных файлов BAT в Windows)

make install (Устанавливает политику в систему, но не загружает в ядро)

shutdown –r now (Перезагрузка системы. После перезагрузки новая политика будет загружена в систему и внесенную изменения вступят в силу)