Фей Кокер (Faye Coker)
[email protected]
Перевод: © Иван Песин
Последнее обновление: 06 декабря 2003
Данный документ исправлен и дополнен, чтобы соответствовать особенностям новой реализации SE Linux. Старый вариант документа "Getting Started with SE Linux HOWTO" остается в силе, однако для всех новых инсталляций SE Linux рекомендуется использовать новую реализацию SE Linux. Новая реализация SE Linux работает на ядрах ветки 2.6.x, а также была портирован для ветки 2.4.x. Этот документ во многом дублирует предыдущий, однако содержит необходимые изменения.
Документ представляет собой введение в NSA Security Enhanced Linux. В основном рассматривается дистрибутив Debian, потому примеры команд по управлению пакетами специфичны для Debian. Этот документ предназначен людям, которые хотят начать использовать SE Linux, так что сложные моменты не рассматриваются. В разделе "Ссылки" представлены ссылки на различные материалы по SE Linux.
Содержание
Данный документ составлен в ответ на просьбы людей о вводном курсе для SE Linux. Он охватывает базовые аспекты SE Linux, такие как терминология, установка и добавление новых пользователей, а так же некоторые другие. Кроме того, будет составлен более углублённый документ, который рассмотрит вопросы редактирования файлов политик (обычно, начинающий пользователь SE Linux с таким объемом информации справиться не может, потому здесь она не включена).
Приветствуются комментарии по данному документу. Пожалуйста, пишите на адрес [email protected]
Этот документ всего лишь руководство. Я настойчиво рекомендую вам для начала устанавливать SE Linux на тестовой машине и лишь потом на производственных серверах.
Новая реализация SE Linux включает значительное число новых функций. Давайте рассмотрим их.
Файловая система /selinux
Появилась новая файловая система /selinux. При установке
необходимо соответствующим образом отредактировать файл
/etc/fstab. Как и файловая система /proc,
/selinux является псевдофайловой системой. При выполнении
команды ls -l /selinux мы получим
total 0 -rw-rw-rw- 1 root root 0 Nov 25 11:27 access -rw-rw-rw- 1 root root 0 Nov 25 11:27 context -rw-rw-rw- 1 root root 0 Nov 25 11:27 create -rw------- 1 root root 0 Nov 25 14:19 enforce -rw------- 1 root root 0 Nov 25 11:27 load -r--r--r-- 1 root root 0 Nov 25 11:27 policyvers -rw-rw-rw- 1 root root 0 Nov 25 11:27 relabel -rw-rw-rw- 1 root root 0 Nov 25 11:27 user
Если вывести файл "enforce", то будет показана либо 1 в принудительном (enforcing) режиме, либо 0 в разрешающем (permissive) режиме.
Использование расширенных атрибутов
Новая реализация SE Linux использует расширенные атрибуты для
хранения контекста безопасности. Ваше ядро должно иметь поддержку
расширенных атрибутов. Расширенные атрибуты представляют собой
кортежи, вида "имя-данные". Например,
security.selinux это имя атрибута, а контекст
безопасности -- это данные. Контекст безопасности файла можно
просмотреть с помощью команды ls --context filename
(рассмотрено далее в документе) при работающем SE Linux, иначе
необходимо использовать команду getfattr. Помните, что вам
нужно установить пакет attr и прочесть страницу
руководства команды getfattr. Выполнение команды даёт
следующие результаты:
faye@kaos:~$ getfattr -m . -d /etc/passwd getfattr: Removing leading '/' from absolute path names # file: etc/passwd security.selinux="system_u:object_r:etc_t\000"
Атрибут security.selinux имеет контекст, соответствующий запрашиваемому файлу. Т.е. в вышеприведённом примере контекст это system_u:object_r:etc_t. Все файлы на файловых системах ext2 и ext3 в новом SE Linux имеют атрибут security.selinux (новая важная особенность). Если вы загрузитесь с ядром без поддержки SE Linux, расширенные атрибуты не исчезнут, и вы сможете видеть их. Расширенные атрибуты устанавливаются при запуске команды setfiles, которая устанавливает контекст безопасности файлов в рамках операции make relabel.
Загрузка политики SE Linux процессом init .
Теперь на процесс init возложены функции по монтированию файловой
системы /selinux и загрузке политики.
SID и PSID больше не используются
Идентификаторы безопасности (SID, Security Identifiers)
использовались в старой реализации SE Linux в интерфейсе к ядру (из
пользовательского пространства). Персистентные идентификаторы
безопасности (PSID, Persistent SID) использовались в коде ядра для
отображения файлов в контексты для файлов и каталогов на диске.
Обратитесь к документу NSA "Настройка
политики SELinux" за подробной информацией по этому вопросу. В
новой реализации SE Linux, расширенные атрибуты содержат контекст,
потому идентификаторы больше не нужны.
Сокращённый параметр -Z
Параметр -Z может использоваться вместо --context после таких
команд, как ls и ps.
Команда chsid удалена: используйте команду
chcon .
Команда chsid применялась в старой реализации SE Linux
для изменения контекста файла. В новой реализации для этих целей
применяется команда chcon. Эта команда присутствовала и в
старом SE Linux, но была переработана и поддерживает установку
пользователя и типа. Обратитесь к руководству за подробностями.
В дистрибутиве Debian, исходные тексты политики расположены в каталоге /etc/selinux. В Fedora они находятся в /etc/security/selinux/src/policy. В данном документе я использую каталог в дистрибутиве Debian, так что если вы пользователь Fedora заменяйте /etc/selinux на /etc/security/selinux/src/policy.
В этом разделе приведены некоторые сведения, которые объясняют для чего нужно использовать SE Linux и как он работает. Раздел 2.2 определяет термины, которые будут часто использоваться в дальнейших разделах, поэтому в них нужно хорошо разобраться.
SE Linux обеспечивает большую безопасность вашей системы. Пользователям могут быть назначены предопределённые роли таким образом, что они не смогут получить доступ к файлам и процессам, которыми они не владеют. При этом не существует эквивалента операции "chmod 777". Это отличается от обычной системы Unix-привилегий в том, что определённые пользователем роли, или контексты безопасности в которых они находятся, имеют ограниченный, но более управляемый доступ к файлам и другим ресурсам. Рассмотрим пользовательский файл .rhosts на обычной Unix системе. Если всем дать доступ на запись в этот файл, тогда кто угодно сможет зайти в систему и причинить массу неприятностей. Используя SE Linux, вы можете контролировать возможность пользователя изменять права доступа в своему файлу .rhosts, а кроме того запретить другим людям писать в этот файл даже после того, как владелец это разрешил.
Частый вопрос, это как связаны права доступа SE Linux и стандартные права Unix. Когда вы выполняете какую-либо операцию, в первую очередь проверяются права доступа Unix. Если они разрешают выполнить операцию, тогда проверяются права SE Linux. Только тогда операция будет разрешена или запрещена. Но если права доступа Unix запрещают операцию, то проверка прав SE Linux не производится, а операция запрещается.
Рассмотрим другой пример. Допустим, есть ошибка в программе /usr/bin/passwd, которая позволяет выполнить команду chmod 666 /etc/shadow. В этом случае вступают в действия права SE Linux, которые предотвратят неавторизированный доступ к файлу.
Чтобы не цитировать документ NSA FAQ, я просто даю на него ссылку -- http://www.nsa.gov/selinux/faq.html Чтение официальных документов, которые публикует NSA обязательно.
Следующие термины будут часто употребляться в этом документе и формируют концептуальную основу SE Linux. Весьма сложно определить одно слово, не употребляя при этом других, требующих определения. Я понимаю, что мои определения содержат то, что требует определения. ;)
Сущность в SE Linux это не то же, что и традиционный идентификатор пользователя (Unix uid, user id). Они могут сосуществовать в одной системе, но их смысл совершенно разный. Сущность в SE Linux формирует часть контекста безопасности, который задает домены, в которые можно войти. Т.е. что собственно можно сделать. Сущность SE Linux может иметь одинаковое с именем пользователя символьное представление (чаще всего так и есть), но важно понимать, что это две разные вещи. Выполнение команды su не меняет сущности пользователя в SE Linux.
Пример:
Непривилегированный пользователь faye выполняет команду
id (в SE Linux) и видит свой контекст безопасности:
context=faye:user_r:user_t
Часть контекста "faye" представляет сущность. Теперь, пользователь faye выполняет su, чтобы получить привилегии пользователя root, и вызывает id, и видит, что контекст всё ещё:
context=faye:user_r:user_t
то есть, контекст остался прежним и не изменился на контекст пользователя root. Однако, если сущность faye разрешает доступ к роли sysadm_r, и пользователь это сделает (введя команду newrole -r, детальнее команда рассматривается ниже), и снова выполнит id, то увидит уже:
context=faye:sysadm_r:sysadm_t
Итак, сущность осталась той же, но роль и домен (второе и третье поле соответственно) изменились. Такой стиль работы с сущностью обеспечивает возможность идентификации пользователя. Ключевым моментом в безопасности системы является то, что сущность пользователя определяет какие роли и домены могут быть использованы.
Каждый процесс выполняется в домене. Домен однозначно определяет привилегии процесса. По существу домен это список того, что может делать процесс, или какие действия процесс может выполнять над различными типами. Представляйте себе домен, как стандартный Unix uid. Пускай у пользователя root есть какая-то программа, для которой он выполнил команду chmod 4777 (установил атрибут setuid). Кто угодно в системе, даже пользователь nobody, может выполнить эту программу с полномочиями пользователя root, тем самым, нарушая безопасность системы. При использовании SE Linux, процесс, инициирующий переход в привилегированный домен, должен иметь роль, которой разрешено использовать этот домен, иначе процесс работать не сможет.
В качестве примеров доменов можно привести sysadm_t, домен системной администрации, и user_t, который является общим доменом для непривилегированных пользователей. Процесс init выполняется в домене init_t, а named -- в домене named_t.
Тип задаётся для объекта и определяет доступ к этому объекту. Т.е. это приблизительно то же самое, что и домен, но домен относится к процессам, а тип к таким объектам, как каталоги, файлы, сокеты и т.п.
Роль определяет, какие домены могут быть использованы. Домены, к которым имеет доступ пользовательская роль, предопределяются в конфигурационных файлах политики. Если роль не имеет доступа к заданному домену (в базе данных политики), то при попытке выполнить это действие доступ будет запрещён.
Пример:
для того, чтобы разрешить пользователю из домена user_t (домен
непривилегированных пользователей) выполнять команду
passwd, в соответствующем файле конфигурации указано:
role user_r types user_passwd_t
Она означает, что пользователь с ролью user_r может входить в домен user_passwd_t, т.е. может выполнять команду passwd.
Контекст безопасности это набор всех атрибутов, связанных с объектами типа файлов, каталогов, процессов, 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, т.к. она не поддерживает изменение меток.
Контекст безопасности файла, например, может варьироваться в зависимости от домена, который создал файл. По умолчанию, новый файл или каталог наследует тип от родительского каталога, однако вы можете задать иную политику.
Пример:
пользователь faye создаёт файл test в своем домашнем каталоге.
После чего выполняет команду ls --context test и
видит:
-rw-r--r-- faye faye faye:object_r:user_home_t test
Теперь faye создаёт файл в каталоге /tmp с именем tmptest и выполняет команду ls --context /tmp/tmptest. Теперь результат такой :
-rw-r--r-- faye faye faye:object_r:user_tmp_t /tmp/tmptest
В первом примере контекст безопасности включал тип "user_home_t", который является типом по умолчанию для домашнего каталога непривилегированного пользователя с ролью user_r. После выполнения второй команды ls --context, видим, что тип теперь user_tmp_t. Это тип по умолчанию для файлов, созданных процессами домена user_t в каталоге типа tmp_t.
Решение о переходе, определяет контекст безопасности, который будет назначен запрошенной операции. Есть два основных типа переходов. Первый тип, это переход домена процесса. Он используется при выполнении процесса определённого типа. Второй, это переход типа файла, который применяется при создании файла в определённых каталогах.
Пример:
Пример перехода второго типа (переход типа файла) приведён в
предыдущем разделе "контекст безопасности". При выполнении команды
ls --context вы можете видеть тип файла (т.е. user_home_t и
user_tmp_t в вышеприведённом примере). Итак, при создании
пользователем файла в каталоге /tmp происходит переход в тип
user_tmp_t и новый файл помечается соответствующим образом.
Рассмотрим теперь пример перехода домена процесса. Запустите ssh из-под обычного пользователя, или, точнее, из домена user_t (помните, что для проверки текущего контекста безопасности можно использовать команду id). Теперь выполите ps ax --context и найдите строку с данными о команде ssh. Полагая, что это сделал пользователь faye, она, в частности, увидит:
faye:user_r:user_ssh_t
Процесс ssh выполняется в домене user_ssh_t потому что программа имеет тип ssh_exec_t, а роль user_r имеет право доступа в домен user_ssh_t.
Политики -- это наборы правил, контролирующие такие вещи как список ролей, к которым имеет доступ пользователь, какие роли имеют доступ к каким доменам и какие домены имеют доступ к каким типам. Вы можете редактировать файлы политик в соответствии с тем, как вы хотите настроить свою систему.
Данный раздел описывает процедуру инсталляции пакетов для новой реализации SE Linux. Поскольку я работаю с Debian, мои инструкции относятся к этому дистрибутиву. Предполагается, что вы знаете, как устанавливать пакеты в вашем дистрибутиве, как компилировать ядро и накладывать на ядро патчи.
Если вы обновляетесь со старой версии SE Linux на новую, и работаете с ядром, поддерживающим SE Linux, вам следует перейти в разрешающий режим (при помощи команды avc_toggle) и следовать приведённым инструкциям.
Для Debian unstable:
Поместите следующую строку в файл /etc/apt/sources.list :
deb http://www.coker.com.au/newselinux/ ./
Пакеты для ветки unstable поддерживаются Расселом Кокером (Russell Coker).
На момент написания документа (конец ноября 2003) пакетов с новой реализаций SE Linux для ветки stable не было. Файлы .deb могут быть загружены с указанного узла. Обязательно загружайте самые свежие пакеты. Я не указываю полных имён пакетов, поскольку они постоянно меняются.
Вот список пакетов, которые необходимо установить для работы нового SE Linux на системе Debian unstable. Вам не нужно загружать ядро с поддержкой SE Linux для установки этих пакетов:
Ниже приведены дополнительные пакеты для Debian, которые вам понадобятся.
Пользователи Debian должны быть знакомы с командами dselect, apt-get и dpkg. se_dselect, se_apt-get и se_dpkg представляют собой скрипты-надстройки для вызова обычных версий ds-elect, apt-get и dpkg, но с некоторыми нюансами. То же самое относится и к se_dpkg-reconfigure. Зачем нужны эти модифицированные версии? Чтобы корректно маркировать файлы устанавливаемых пакетов и запускать скрипты в нужном контексте.
При использовании этих команд у вас запросят подтверждение пароля (пароль сущности, которую вы используете). Зачем? Для примера возьмём команду se_dselect. Запустим её из контекста sysadm_r:sysadm_t. Теперь из другого сеанса, с тем же контекстом, выполним ps ax --context|grep dselect и увидим что-то вроде:
5292 404 system_u:system_r:dpkg_t dselect
обратите внимание на контекст безопасности, в котором сейчас выполняется dselect. Как видите, изменилась сущность, роль и домен. Потому для выполнения этой программы вам нужно подтвердить свой пароль.
Пакеты RPM с новой реализацией SE Linux могут быть получены с узла ftp://people.redhat.com/dwalsh/SELinux
Эти пакеты поддерживаются Дэном Уолшем (Dan Walsh).
Для установки SE Linux на тестовой машине с дистрибутивом Fedora я сделала следующее:
* отредактировала файл yum.conf, чтобы он содержал такие строки:
[main] cachedir=/var/cache/yum debuglevel=2 logfile=/var/log/yum.log pkgpolicy=newest distroverpkg=fedora-release tolerant=1 exactarch=1 [development] name=Fedora Core $releasever - Development Tree #baseurl=http://download.fedora.redhat.com/pub/fedora/linux/core/development/i386 baseurl=http://mirror.dulug.duke.edu/pub/fedora/linux/core/development/i386 [SELinux] name=SELinux repository baseurl=ftp://people.redhat.com/dwalsh/SELinux/Fedora
* установила соответствующие пакеты
yum install policy checkpolicy policycoreutils policy-sources pam passwd vixie-cron
* после этого, выполнила такие команды
cd /etc/security/selinux/src/policy make load make relabel
* перезагрузила машину.
В старой реализации SE Linux пакеты было необходимо устанавливать в определённом порядке, например, в первую очередь следовало устанавливать обновлённый пакет login. В настоящий момент порядок установки определяют зависимости пакетов.
Пакет kernel-patch-2.4-lsm устанавливает необходимый патч LSM для нового SE Linux. Он содержит поддержку LSM и код SE Linux, который её использует.
Теперь прочтите /usr/share/doc/kernel-patch-2.4-lsm/README.Debian и следуйте инструкциям по установке параметров CONFIG_ для компиляции вашего ядра. После чего переходите к компиляции нового ядра или используйте make-kpkg для создания пакета.
Вот выдержка из /usr/share/doc/kernel-patch-2.4-lsm/README.Debian:
Данный патч реализует поддержку Linux Security Modules. Она необходима для NSA Security Enhanced Linux (среди прочего). Для автоматического наката, перед первым запуском make-kpkg (из пакета: kernel-package) установите PATCH_THE_KERNEL=YES и выполните "make-kpkg clean". Во время конфигурации ядра выберите следующие параметры: (В Networking Options, выберите Network Packet Filtering. В Security Options, выберите Capabilities, IP Networking и SELinux. Последние две опции должны быть скомпилированы статически.) Это означает, что в вашем конфигурационном файле /usr/src/linux/.config должно присутствовать: CONFIG_NETFILTER=y CONFIG_INET=y CONFIG_SECURITY=y CONFIG_SECURITY_CAPABILITIES=y CONFIG_SECURITY_SELINUX=y CONFIG_SECURITY_DTE=n CONFIG_SECURITY_OWLSM=n CONFIG_LIDS=n Данная версия SE Linux требует поддержки XATTR. Для файловой системы Ext3 Используйте параметры: CONFIG_EXT3_FS_XATTR=y CONFIG_EXT3_FS_XATTR_SHARING=y CONFIG_EXT3_FS_SECURITY=y Параметры CONFIG_EXT3_FS_XATTR_USER и CONFIG_EXT3_FS_XATTR_TRUSTED для SE Linux не требуются, но и не мешают.
Если вы скомпилировали ядро с параметром CONFIG_SECURITY_SELINUX_DEVELOP, система будет загружаться в разрешающем режиме, а переход в принудительный режим должен осуществляться вручную. Если же этот параметр не был задан, то после загрузки вы будете работать в принудительном режиме, без возможности переключиться в разрешающий режим. Подробнее это рассматривается в разделе 4.4: Разрешающий и принудительный режимы.
Если вы используете файловую систему ext2, вам необходимо собрать ядро с параметром CONFIG_EXT2_FS_XATTR. Если вы хотите иметь возможность монтировать файловую систему ext3, не создавая при этом расширенных атрибутов, то в этом случае компиляция ext2 без поддержки XATTR может быть одним из решений. Тогда файловую систему ext3 можно смонтировать как файловую систему ext2 без поддержки расширенных атрибутов (просто отредактируйте файл /etc/fstab).
Этот пакет содержит стандартные политики безопасности. Эквивалентный пакет RPM называется policy-sources.
При установке этого пакета в Debian вам будут заданы вопросы о нужных вам политиках. Вы решаете, какие политики вам нужны, а какие нет. Если вдруг окажется, что нужна политика, от которой вы отказались, то в любой момент вы можете её скопировать из /usr/share/selinux/policy/default/domains/program/ в /etc/selinux/domains/program и выполнить из любого каталога команду make -C /etc/selinux load.
Маленькое замечание о политике sendmail.te -- её лучше удалить, поскольку она конфликтует с политиками других почтовых серверов. Естественно, если вы не используете сервер sendmail. В этом случае, вы не будете устанавливать политики других почтовых серверов.
Вопросы будут выглядеть следующим образом:
Removal of unwanted policy files Do you want domains/program/amavis.te:Amavis anti-virus Yes/No/Display[Y/n/d]?
Если вы ответите Y, файл политики amavis.te будет установлен. Если вы ответите n, политика установлена не будет (но вы сможете скопировать её позже, как было указано ранее). Выбор d выведет указанный файл политики.
Когда вы закончите, выбранные политики будут скомпилированы и установлены.
На этом этапе наступает ответственный момент. Каждый файл маркируется контекстом безопасности.
Перед перезагрузкой вам потребуется отредактировать файл /etc/fstab и создать точку монтирования /selinux. Итак, создавайте каталог /selinux и устанавливайте права доступа 500. Теперь вставьте в файл /etc/fstab строку:
none /selinux selinuxfs noauto 0 0
Если у вас установлено ядро 2.6.x с поддержкой XATTR, после создания точки монтирования и редактирования /etc/fstab, вы должны выполнить команду make -C /etc/selinux relabel. Эта команда перемаркировывает файловую систему правильными контекстами безопасности. Обратите внимание, что вам нужно будет выполнить команду повторно, после перезагрузки (обсуждается далее в документе). Если вы используете ядро 2.4.x, то вы не сможете выполнить эту команду, так как ядра 2.4.x без поддержки SE Linux не позволяют задавать расширенные атрибуты.
Перед перезагрузкой мы должны отредактировать файлы /etc/pam.d/login и ssh (sshd в Fedora), чтобы командный интерпретатор запускался в правильном контексте. Добавьте в эти файлы строку:
session required pam_selinux.so
До перезагрузки вы можете добавить нового пользователя для SE Linux командой useradd и отредактировать файл users. Это можно сделать и после перезагрузки. В этом документе мы добавим пользователя позже.
Теперь вы готовы к перезагрузке. Как только вы загрузите ядро, с поддержкой SE Linux, вы будете должны перемаркировать все файловые системы.
В этом разделе мы рассмотрим процесс регистрации пользователя в системе и немного поговорим о контекстах безопасности пользователей. Последний раздел будет посвящен разрешающему и принудительному режимам.
На этом этапе вы должны были уже перезагрузиться и увидеть приглашение в систему. При установке пакета selinux-policy-default (или policy-sources для Fedora), политика разрешает вход в систему для роли пользователя по умолчанию (поскольку новых пользователей мы еще не добавляли).
Зарегистрируйтесь как пользователь root. Ваш контекст безопасности будет root:user_r:user_t. Введите id и посмотрите на контекст. Там должно быть примерно следующее (нас интересует контекст безопасности, на остальную часть вывода сейчас не обращайте внимания):
uid=0(root) gid=0(root) groups=0(root) context=root:user_r:user_t
итак, в этой строке контекст безопасности представлен выражением
root:user_r:user_t
Теперь давайте представим, что вы ранее разрешили доступ своему пользователю к другой роли. Этому посвящён раздел 5: Создание учётных записей пользователей. Есть два способа переключения между ролями. Во-первых, при регистрации. Допустим, пользователю faye разрешено входить в домен sysadm_t. При регистрации на консоли она увидит вопрос "Your default context is faye:user_r:user_t. Do you want to choose a different one? [n]" (Ваш контекст по умолчанию faye:user_r:user_t. Хотите выбрать другой?). Если пользователь ответит y, система даст возможность выбора контекста:
[1] faye:user_r:user_t [2] faye:sysadm_r:sysadm_t Enter number of choice:
В этом примере мы видим, что сущности "faye" разрешён доступ к роли sysadm_r и домену sysadm_t. Выводятся лишь те варианты, к которым имеет доступ сущность. Обратите внимание, что это работало в старой реализации SE Linux и будет настраиваемой возможностью в новой реализации SE Linux (не доступной на момент написания), которая по умолчанию будет выключена.
Если пользователь faye выберет второй вариант (чтобы получить роль sysadm_r), после чего вызовет команду id, она увидит, что её контекст теперь:
context=faye:sysadm_r:sysadm_t
Перейдём теперь ко второму способу переключения контекстов.
Второй способ переключения контекстов безопасности -- это команда newrole -r. Синтаксис этой команды:
newrole -r role
где role -- это роль, которую вы хотите получить. Например, если вы хотите получить роль sysadm_r, вы должны ввести:
newrole -r sysadm_r
Вас попросят подтвердить пароль для вашей сущности, увидеть которую вы можете с помощью команды id. Если у вас нет прав доступа к указанной роли, вы увидите следующее сообщение (положим, что сущность fred пытается получить доступ к роли sysadm_r):
fred:sysadm_r:sysadm_t is not a valid context
Это сообщение означает, что fred не может войти в sysadm_r:sysadm_t роль/домен, так как у него нет на это прав.
После успешного изменения роли используйте команду id для проверки своего текущего контекста.
Для выполнения команд из домена sysadm_t ваша роль должна быть sysadm_r. Сейчас мы должны немного прибраться после установки, так что давайте зарегистрируемся в системе как пользователь root. Вас не будут спрашивать о контексте.
Я должна извинится за некоторую непоследовательность и повторяемость в инструкциях. В этом документе мы ещё не разрешали пользователю root доступ к роли sysadm_r и вы, вероятно, думаете о том, как мы сможем выполнять административные задачи из контекста user_r:user_t. Мы работаем в разрешающем режиме, который лишь имитирует выполнение политики безопасности и протоколирует результат. Кроме того, вы можете использовать команду newrole -r для переключения в роль sysadm_r. Если вы попытаетесь выполнить что-либо, для чего у вас нет полномочий, вы получите не один экран сообщений об ошибках.
Итак, получите роль sysadm_r и проверьте свой контекст командой id.
Теперь мы можем работать дальше. Когда мы установили все необходимые пакеты в разделе 3, мы пометили все файлы файловой системы. Но SE Linux ещё не был запущен. Таки образом, если файл был создан после процесса маркировки, но до загрузки ядра SELinux, то он не имеет ассоциации с типом. Например, файлы могли создаться во время завершения работы системы. Возможен другой вариант, вы удалили файл. Теперь освободившийся индексный дескриптор может быть использован для другого файла и в результате новый файл получит тип удаленного. Это может причинить массу хлопот.
Рассмотрим файл /etc/nologin. Он создается при выполнении команды shutdown. Если этот файл существует при загрузке системы, зарегистрироваться может только пользователь root. Что случится, если скрипты загрузки системы не смогут удалить этот файл? Например, если метка файла будет неправильной? Если пользователь root имеет доступ к роли sysadm_r, то вы можете зарегистрироваться в системе и удалить этот файл -- проблема решена.
Что случится, если вы не дали прав доступа к роли sysadm_r сущности root? В этом случае, контекст может быть root:user_r:user_t. Но домен user_t не дает вам возможности удалять что-либо из каталога /etc. Вот и проблема! Вы можете зарегистрироваться как пользователь root, но у вас нет привилегий роли sysadm_r чтобы что-то сделать.
Далее, допустим, что у вас есть своя сущность с именем "faye". Этой сущности назначена роль sysadm_r. То есть faye может выполнять работу в роли sysadm_r, которую не может выполнить сущность root (поскольку находится в роли user_r, домен user_t). но в данном случае, это бесполезно, ведь сущность faye не сможет зарегистрироваться в системе из-за существующего файла /etc/nologin !
Вот почему правильная маркировка файлов критична. Давайте теперь вернёмся к процессу маркировки. Нам необходимо ещё раз выполнить команду
make -C /etc/selinux relabel
Она корректно перемаркирует все файлы в системе. Время, необходимое на этот процесс зависит от быстродействия вашего компьютера. Приблизительно, это займет столько же времени, сколько команда find / . Не забудьте сменить вашу роль на sysadm_r, т.к. если ваша роль (например, user_t) не имеет прав доступа к другим доменам, вы получите огромное количество сообщений "отказано в доступе".
Разрешающий режим -- это режим, в котором SE Linux лишь протоколирует сообщения, ничего более того (вы можете работать точно так же, как и на машине без SE Linux). Принудительный режим -- это режим, в котором применяются все настроенные политики. Собственно, только теперь SE Linux начал работать. Разрешающий режим хорош для отладки работы системы. Сообщения можно увидеть с помощью команды dmesg.
Предупреждение: загружайтесь в принудительном режиме только когда у вас всё настроено! Для настройки используйте разрешающий режим. В нём файлам назначаются метки, работает вся функциональность SE Linux, но ничего не запрещается, только протоколируется. Некоторые люди компилируют ядро без параметра CONFIG_SECURITY_SELINUX_DEVELOP, в результате они вообще не могут попасть в разрешающий режим.
Для переключения в принудительный режим используйте команду echo "1" > /etc/selinux/enforce . Чтобы вернуться обратно в разрешающий режим, замените 1 на 0. В старой реализации SE Linux использовалась команда avc_toggle, которая отсутствует в новой реализации. Просто просмотрев файл /etc/selinux/enforce, вы увидите режим, в котором работает система (раньше использовалась команда avc_enforcing).
В разделе 7: разбор стандартных сообщений приведены примеры сообщений, выводящихся при переключении режимов.
Если вы скомпилировали ядро в режиме разработки (т.е. ваша система загружается в разрешающий режим, и вручную переключается в принудительный), то для того, чтобы переключатся в принудительный режим во время загрузки можно создать скрипт или передать ядру параметр enforcing=1 (например, указав в файле lilo.conf строку append="enforcing=1"). (Пробел не забудьте: append=" enforcing=1", иначе ядро не сможет обработать корректно параметры и они не вступят в силу. -- прим.ред.)
Давайте теперь запустим некоторые команды в разных контекстах безопасности. Переключитесь в принудительный режим. Из вашей роли user_r запустите команду ps ax --context и посмотрите на результат. Не забывайте, что вместо длинного ключа можно использовать короткий : ps ax -Z. Из роли user_r вы видите процессы, которые находятся в домене user_t и других доменах, к которым есть доступ в каталоге /proc. Если у вас нет доступа к подкаталогам в каталоге /proc, тогда процессы не будут отображены в выводе команды ps ax.
Теперь выполните команду ps ax --context в домене sysadm_t. Теперь вы увидите все процессы, вне зависимости от их домена. Домен sysadm_t имеет доступ к другим доменам, в отличие от user_t. Вот почему вы не видели всех процессов из домена user_t. Представим, что злоумышленник может увидеть все процессы системы. Тогда он может увидеть какой-то демон, в котором может быть уязвимость и воспользоваться ею. Риск значительно уменьшается, если обычные пользователи не могут увидеть список процессов.
Другим примером уязвимости могут служить программы, которым пароль передается параметром командной строки. В обычной Linux-системе такой пароль будет виден всем пользователям, тогда как SE Linux этого не допустит (конечно, пароль в командной строке -- это все равно плохо).
Переключитесь назад в разрешающий режим. Теперь вы сможете видеть все процессы из домена user_t.
Перейдем теперь к более интересным вещам! Мы создадим нового пользователя, назначим ему роль и установим для пользователей контекст безопасности по умолчанию. В старом SE Linux были специальные программы-надстройки для vipw (это была svipw), useradd (suseradd), passwd (spasswd), chfn (schfn) и т.п. В новой реализации ничего такого нет и используются обычные команды (т.е. НЕ svipw и пр.).
Создадим нового пользователя с именем setest.
Переключимся в sysadm_r:sysadm_t роль:домен и добавим нового пользователя setest:
root@kaos:~# id uid=0(root) gid=0(root) groups=0(root) context=faye:sysadm_r:sysadm_t sid=398
Итак, uid у нас 0, роль:домен -- sysadm_r:sysadm_t. Если это не так, переключитесь к root командой su, потом войдите в роль sysadm_r командой newrole -r.
root@kaos:~# useradd -c "SE Linux test user" -m -d /home/setest -g users -s /bin/bash -u 1005 setest root@kaos:~# finger setest Login: setest Name: SE Linux test user Directory: /home/setest Shell: /bin/bash Never logged in. No mail. No Plan. root@kaos:~# passwd setest Enter new UNIX password: Retype new UNIX password: passwd: password updated successfully
Пользователь setest добавлен.
Нам необходимо назначить роль пользователю setest. Допустим, мы хотим дать доступ к роли user_r. Настраивается это в файле /etc/selinux/users, так что открываем его в редакторе.
В конце файла добавьте строку:
user setest roles { user_r };
эта строка означает, что пользователь setest имеет доступ к роли user_r. если вы хотите, чтобы пользователь имел доступ к роли sysadm_r, то вместо этой строки, добавьте:
user setest roles { user_r sysadm_r };
Теперь нужно активировать изменения, внесённые в /etc/selinux/users. Для этого из роли:домена sysadm_r:sysadm_t выполняем:
make -C /etc/selinux load
Эта операция занимает некоторое время, т.к. создается база политики и сжимается с помощью gzip. После завершения вы увидите:
Success touch tmp/load make: Leaving directory `/usr/share/selinux/policy/current'
Если у пользователя роль по умолчанию user_r, то его не обязательно явно прописывать в файле /etc/selinux/users. Это имеет смысл лишь в том случае, если пользователю необходима возможность менять свой пароль, иметь доступ к другим ролям или видеть имя пользователя в сообщениях SE Linux, где это возможно.
Теперь мы должны задать контекст безопасности по умолчанию.
После добавления нового пользователя в файл /etc/selinux/users, нужно назначить контекст безопасности по умолчанию для пользовательских сеансов. Это делается в файле /etc/security/default_context. В нём вы увидите строку:
system_r:local_login_t user_r:user_t
При локальной регистрации пользователя (т.е. с консоли), запускается программа /bin/login в домене local_login_t. После регистрации, она присваивает сессии роль:домен user_r:user_t. Если бы вместо этой строки в файле было указано:
system_r:local_login_t sysadm_r:sysadm_t user_r:user_t
и регистрирующийся пользователь имел доступ в домен sysadm_t, тогда бы он сразу в него и входил. Если у пользователя нет доступа к этому домену, он попадал бы в домен user_t.
Обратите внимание на строку
system_r:sshd_t user_r:user_t
она говорит, что после регистрации через ssh, пользователь будет попадать в user_r:user_t роль:домен.
Если для добавления пользователя с ролью user_r вы использовали команду useradd, то все файлы маркированы правильно. Если же вы пользовались чем-то вроде vipw, или пользователь должен иметь другую роль, то необходимо провести маркировку файлов:
find /home/setest | xargs chcon -h system_u:object_r:user_home_t ; chcon -h system_u:object_r:user_home_dir_t /home/setest
Эта команда выполняет chcon (изменение контекста безопасности) для всех файлов в каталоге /home/setest . Домашнему каталогу пользователя присваивается тип user_home_dir_t , а файлам в нём -- user_home_t. Иногда, процесс может иметь доступ в домашний каталог пользователя, но не иметь доступа к файлам и каталогам в нём. Поэтому используются два разных типа.
Давайте теперь создадим наш собственный пользовательский домен и назовём его second_t. Также создадим новую роль second_r . Повторив процедуру из раздела 5.2, назначьте пользователю spike роль second_r (которого еще не существует, мы создадим его позже), но не выполняйте команды make. Вместо этого, начните выполнять инструкции из этого раздела.
Мы не вызываем команды make, потому что в предыдущем разделе мы назначали существующую роль user_r. А сейчас нам нужно создать новую роль и новый домен. Давайте займёмся этим.
/etc/selinux/domains/user.te -- это конфигурационный файл пользовательских доменов. Просмотрите его. Теперь добавьте где-нибудь, можно в начале файла, строки
full_user_role(second) allow system_r second_r allow sysadm_r second_r
Обратите внимание на комментарий:
# if adding new user roles make sure you edit the in_user_role macro in # macros/user_macros.te to match # при добавлении новой пользовательской роли отредактируйте соответствующий # макрос in_user_role в файле macros/user_macros.te
Так что нужно отредактировать файл /etc/selinux/macros/user_macros.te. Открываем этот файл в редакторе и ищем строку in_user_role (где-то в конце файла). И добавляем строку "role second_r types $1;" следующим образом:
undefine(`in_user_role') define(`in_user_role',`role user_r types $1;role second_r types $1;')
Теперь давайте детальнее разберем, что мы сделали. Первая строка конфигурации в этом разделе (full_user_role(second)) создаёт домен second_t и типы : second_home_dir_t и second_home_t (соответственно: для домашнего каталога и файлов в нём). Для файлов в каталоге /tmp создаётся тип second_tmp_t. Для разделяемой памяти, созданной в контексте tmpfs, создаётся тип second_tmpfs_t. Наконец, создаются типы second_tty_device_t и second_devpts_t для маркирования устройств tty и псевдо tty. Кроме того, эта директива определяет некоторые базовые политики, связанные с этими типами.
SE Linux не поддерживает объектно-ориентированного подхода, наследования доменов/типов и т.п. Также сейчас нет языка для определения политик, который поддерживал бы эти функции (хотя его можно написать, но пока этого никто не сделал). Потому, для упрощения создания новых доменов, мы используем макросы M4.
Теперь создадим тестового пользователя, который будет иметь доступ к домену second_t и роли second_r.
С помощью команды useradd создайте нового пользователя (допустим, он будет называться "spike"). Добавьте в файл /etc/selinux/users запись для spike, которая разрешит ему доступ к роли second_r. После чего активируйте изменения:
make -C /etc/selinux load
Теперь мы должны задать домен по умолчанию для новой роли. Для этого в файл /etc/security/default_type добавляем:
second_r:second_t
Наконец, вручную перемаркируем каталог /home/spike и его содержимое. Команда useradd этого не делает поскольку поддерживает перемаркировку только для роли user_r. Выполните команду:
find /home/spike | xargs chcon -h system_u:object_r:second_home_t ; chcon -h system_u:object_r:second_home_dir_t /home/spike
Теперь зарегистрируйтесь в системе как пользователь spike.
Ниже приводятся примеры сообщений системы SE Linux. Я объясню значение каждой части сообщения. Для облегчения чтения, сообщения разбиты на строки.
Иногда сообщения не так понятны, как хотелось бы. Потому удобно помнить, что в ReiserFS и Ext2/Ext3 (файловых системах, поддерживающих SE Linux), корневой индексный дескриптор (inode) равен 2.
Файловые системы XFS и JFS на текущий момент не оттестированы в достаточной мере.
Пример 1
avc: denied { getattr } for pid=6011 exe=/usr/bin/vim path=/etc/shadow dev=03:03 ino=123456 \
scontext=faye:user_r:user_t tcontext=system_u:object_r:shadow_t tclass=file
В этом примере непривилегированный пользователь (faye) попытался отредактировать файл /etc/shadow, когда система был в принудительном режиме.
avc: denied означает, что операция была
запрещена.
{ getattr } означает, что была попытка выполнить
операцию stat(). В этом случае, была попытка прочесть атрибуты
файла, которая не удалась.
Содержимое скобок {} содержит операцию или операции, связанные с выполняемыми SE Linux действиями. Протоколироваться могут как успешные действия, так и действия, в выполнении которых было отказано. В этом случае, в действии было отказано.
for pid= идентификатор процесса, выполнившего
операцию.
exe=/usr/bin/vim выполняющаяся команда (в этом
случае -- vim).
path=/etc/shadow путь к объекту, над которым
проводилась операция.
dev=03:03 номер блочного устройства, на котором
расположена файловая система, в которой выполнялось действие.
Первые цифры "03" означают hda, вторые -- 3 раздел. Т.е. "dev=03:03"
указывает на устройство /dev/hda3 (или, если вы используете devfs,
/dev/ide/host0/bus0/target0/lun0/part3). Когда SE Linux проверяет
права доступа, полный путь к объекту не известен. Потому в
протоколе регистрируется устройство и местоположение объекта на
этом устройстве. Допустим, вы обращаетесь к файлу /etc/shadow. SE
Linux не знает, что файл находится на корневой файловой системе.
Известно лишь, что это файл /etc/shadow на текущей файловой
системе.
ino=123456 индексный дескриптор объекта (в этом
случае /etc/shadow)
scontext=faye:user_r:user_t контекст процесса,
выполняющего операцию.
tcontext=system_u:object_r:shadow_t контекст
безопасности целевого объекта (/etc/shadow).
tclass=file означает, что целевой объект это
файл.
Пример 2
avc: granted { avc_toggle } for pid=6073 exe=/sbin/avc_toggle \
scontext=faye:sysadm_r:sysadm_t tcontext=system_u:system_r:kernel_t tclass=system
avc: granted означает, что операция была
разрешена к выполнению.
{ avc_toggle } означает, что программа обратилась
к системному вызову avc_toggle().
tclass=system означает, что целевой процесс
принадлежит к системному классу.
Пример 3
avc: denied { append } for pid=6153 exe=/bin/bash path=/.bash_history dev=03:03 ino=498 \
scontext=faye:user_r:user_t tcontext=faye:object_r:root_t tclass=file
это сообщение говорит о том, что сущность faye из user_r:user_t роли:домена попыталась дописать в файл .bash_history пользователя root, который имеет тип root_t, но система отказала в доступе.
Пример 4
avc: denied { write } for pid=605 exe=/bin/touch dev=09:03 ino=2 \
scontext=root:user_r:user_t tcontext=system_u:object_r:root_t tclass=dir
обратите внимание на отсутствие пути в этом примере. Однако мы можем сказать, что это был коневой каталог, т.к. inode равен 2.
Ниже приведены ссылки на материалы по SE Linux. Пожалуйста, прочтите официальные документы NSA.
Официальный сайт NSA находится по адресу http://www.nsa.gov/selinux
Официальный документ SE Linux FAQ находится по адресу http://www.nsa.gov/selinux/faq.html
Опубликованные NSA материалы, отчёты и презентации можно найти по адресу http://www.nsa.gov/selinux/docs.html
NSA ведёт список рассылки для обсуждения SE Linux. Для того, чтобы на него подписаться, следуйте инструкциям по адресу http://www.nsa.gov/selinux/list.html. по этому же адресу находятся архивы рассылки.
Проект SE Linux на Sourceforge находится по адресу http:/sourceforge.net/projects/selinux.
Copyright © 2003, Faye Coker