Каждый субъект и объект идентифицируется собственным контекстом безопасности, которому соответствует идентификатор безопасности 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 в более старых версиях FedoraCore.
2.1.3 Виды политик
В SELinux доступны для использования два вида политик: целевая политика (targetedpolicy) и строгая политика (strictpolicy).
FedoraCore 4 не содержит поддержки строгих политик, при этом вы можете использовать этот тип в FedoraCore 3. Впервые целевая политика была представлена в составе FedoraCore 3. Ее задача заключается в предоставлении дополнительной защиты некоторым наиболее часто используемым демонам: ttpd, dhcpd, mailman, named, portmap, nscd, ntpd, portmap, mysqld, postgres, squid, syslogd, winbind, и ypbind при помощи внедрения Мандатного Управления Доступом (MandatoryAccessControl, MAC). Подобные демоны запускаются в собственном домене, например httpd_t для httpd и named_t для named. Другие демоны в системе, для которых не написана специализированная политика, запускаются в домене unconfined_t. Демоны и системные процессы, работающие в домене unconfined_t, могут использовать только стандартный для Linux Дискреционный метод управления доступом (DiscretionaryAccessControl, 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. Со временем, будем надеяться, что большая часть демонов будет хорошо работать в более ограниченных доменах. Самое большое преимущество, с точки зрения удобства использования, - это отсутствие ограничивающего домена для пользовательских сессий. Поэтому, объединения строгой и целевой политик не произойдет.