SELinux

СЕРГЕЙ ЯРЕМЧУК

SELinux

«Открытое программное обеспечение  играет все более и более важную роль в федеральных IT- системах.

Я восхищен, что эксперты защиты агентства национальной безопасности делают это ценное содействие Open Source».

Jeffery Hunker, Senior Director for Critical Infrastructure at the White House National Security Council

Дистрибутивов Linux существует великое множество, есть среди них предназначенные для конечного пользователя, есть совсем маленькие, как правило, однодискетные, узкоспециализированные, предназначенные для решения конкретных задач, и нашлось место довольно приличной группе, обозначенной как Security enchanced. Хотя грань между всеми этими категориями в большинстве случаев провести довольно трудно. В последней группе особое внимание привлекает Security Enhanced Linux (http://www.nsa.gov/selinux) или просто SELinux, разработанный в недрах U.S. National Security Agency (NSA). Возник этот проект в 2000 году. В разработках участвуют такие организации, как Secure Computing Corporation, Networks Associates Technology Labs и MITRE Corporation и много добровольцев, так как проект распространяется по лицензии GPL. Основной задачей проекта было достижение такого уровня защищенности системы, чтобы можно было спокойно использовать ее в военных и правительственных организациях. Но по большому счету это не совсем дистрибутив, каким привыкли его видеть администраторы. SELinux представляет собой дополнительные расширения к ядру, увеличивающие его защищенность и возможность более гибко и строго работать с правами доступа для конкретных пользователей. Чтобы обеспечить дополнительную гибкость при добавлении новых возможностей с помощью различных add-on был разработан модуль защиты Linux Security Module (LSM), который обеспечивает модульное добавление расширений защиты к стандартному ядру Linux.

Операционные системы должны иметь возможность обеспечить разделение информации, основанной на конфиденциальности и требованиях целостности, для обеспечения защиты системы. Существует несколько моделей контроля доступа, применяемых в различных системах. В UNIX применяется модель Discretionary Access Control (DAC), которая описывает права каждого пользователя по доступу к конкретным файлам, выполняющиеся программы имеют те же права, что и запустивший их пользователь. При необходимости пользователь может предоставлять другим доступ к своим файлам и программам. При такой модели уровень системной защиты остается зависимым от конкретных функционирующих приложений. Например, если программа, функционирующая от имени root, скомпрометирована, то нападавший может вполне получить в системе аналогичные привилегии, так как механизм DAC опирается в своей работе только на тождество пользователя и монопольное использование, игнорируя другую вполне уместную информацию, например, о роли пользователя в системе, функции и уровне доверия конкретной программы и необходимости в целостности данных. Каждый пользователь имеет полную свободу действий в пределах своих полномочий. Другая модель защиты, основанная на принудительном контроле доступа – Mandatory Access Control (MAC) – позволяет настроить доступ, базируясь на решении относительно конкретных документов и классификаций объектов. Причем используются очень строгие правила по типу «что не разрешено явно – запрещено». Но осуществление механизма MAC в UNIX-системах напрямую может привести к образованию большого количества правил, так как придется описывать определенные правила для каждого пользователя и каждой программы, которую он может использовать. Чтобы избежать этого, в SELinux использована концепция роль-основанного контроля доступа Role-Based Access Control (RBAC), с помощью которой администратор системы определяет роли и разрешает пользователям доступ к тем ролям, которые ему действительно необходимы. Определяя роли в системе и объекты в системе, к которым эти роли могут обращаться, и разрешая теперь различным пользователям использовать различные роли, задача определения принудительного контроля доступа существенно упрощается. В SELinux выполнена модель Mandatory Access Control, основанная на Linux-ядре. Администратор системы имеет возможность установить политику защиты, в которой определить, какие из программ к каким файлам могут обращаться. Это несколько напоминает инструкции firewall, индивидуальные для каждого сетевого интерфейса. Механизм защиты в SELinux носит название Type Enforcement (TE) и позволяет закрепить за каждым процессом и файлом, которые необходимо контролировать, некую метку. Теперь к политике, определенной администратором, ядро обращается через сервер защиты, встроенный в ядро, который и решает, допустить ли к процессу или файлу или отвергнуть запрос. Если процесс, запущенный от имени администратора, скомпрометирован, то ущерб, который может быть причинен системе, ограничен только тем, к чему он может обращаться, согласуясь с установленными для него правилами. Дополнительно в SELinux заложена возможность использования многоуровневой модели защиты Multi-Level Security model (MLS), которая используется только в военных и правительственных многопользовательских системах, требующих чрезвычайно высокого уровня защиты. В этой модели все объекты типа файлов могут классифицироваться с уровнями защиты типа «Top Secret», «Secret», «Confidential» и «Unrestricted». При этом информация может переходить от нижнего уровня к верхнему, но никогда в обратном направлении.

Установка SELinux

Так как SELinux – это не полноценный дистрибутив, а видоизмененное ядро с набором патчей для некоторых приложений и утилиты, обеспечивающие работу в новом окружении, поэтому первоначально необходимо иметь уже установленную Linux-систему. В качестве базового может использоваться практически любой дистрибутив со стандартным размещением конфигурационных файлов. Я для установки использовал CRUX (http://crux.nu) – легкий, i686 оптимизированный дистрибутив, рассчитанный на подготовленного пользователя, имеющий удобную систему пакаджей и портов, подобную FreeBSD, и в базовом составе не содержащий ничего лишнего, но имеющий все необходимое для установки SELinux. И к тому же при установке CRUX все равно приходится самостоятельно собирать ядро. Теперь по адресу http://www.nsa.gov/selinux/src-disclaim.html выбираем необходимые пакеты. Советую скачать сразу все необходимое, т.е. LSM-патченное ядро, модули ядра SELinux, набор файлов политик, необходимые программы управления доступом и основные утилиты (ps, cp, find, id, ls, mkdir) с поддержкой режимов работы SELinux. Все это доступно одним архивом, помеченным на сайте единицей. Хотя можно попробовать самому пропатчить ядро и установить необходимые утилиты, но это займет больше времени.

Перед установкой необходимо убедиться, что файловая система отформатирована как ext2 или ext3, установлены необходимые сервисы (Apache, Samba и т. д.), также рекомендовано настроить систему без автоматического запуска X-Window, для чего в файле /etc/inittab необходимо установить 3 уровень запуска (для Red Hat совместимых дистрибутивов). Установить SELinux можно двумя способами, все они описаны в соответствующем README. В простейшем случае после распаковки скачанного архива необходимо отредактировать файл ./selinux/policy/user, в котором определен каждый пользователь, признаваемый системной политикой защиты, т.е. разрешенные роли для каждого пользователя. Необходимо разрешить по крайней мере одному пользователю роль администратора системы (sysadm_r), а для других достаточно будет обычной роли пользователя (user_r). Не забудьте удалить пример jadmin и Jdoe. Далее для конкретной системы необходимо проверить пути к файлам для каждого охраняемого сервиса в файле ./selinux/policy/file_contexts/{types.fc,program/*.fc}. Теперь, зарегистрировавшись как root, вводим make quickinstall, и программа сама выполнит необходимые команды. При конфигурировании ядра не забудьте включить поддержку ext3 и тип процессора. Также обязательно включите следующие опции:

• В Networking Options:

Network Packet Filtering

• И в Security Options:

Enable different security models

    Capabilities Support

    NSA SELinux Support

    NSA SELinux Development Support

Среди опций обнаружилась также LIDS, Linux Intrusion Detection System, помеченная как EXPERIMENTAL, система, позволяющая ограничить в правах даже всемогущего root, но инструментов для конфигурирования данной системы я не нашел. Вообще опции, помеченные как EXPERIMENTAL, рекомендуется включать только для эксперимента.

После окончания процесса компиляции ядра его необходимо скопировать в каталог /boot с префиксом -selinux и затем сконфигурировать загрузчик. После перезагрузки, чтобы не набирать каждый раз полный путь к исполняемым файлам, желательно поместить каталоги /usr/local/selinux/bin и /usr/local/selinux/sbin в переменную $PATH. После этого можно проверить, как работают утилиты, поставляемые с SELinux. Например, команда ps, выводящая информацию о процессах, теперь дополнительно выводит данные о контексте защиты функционирующих процессов.

[root@grinder /]# ps -e –context 

Как видите, в выводе программы добавились два столбца: цифра SID (Security IDentifier tag) – метка идентификатора защитный и ассоцииативный пользователь, роль и тип для отображаемого процесса в формате user:role:domain или user:role:type. Каждый процесс должен иметь свой собственный отдельный домен. Если некоторые системные процессы функционируют в домене initrc_t , то либо он не был передвинут в отдельный домен, или, скорее всего, в файле ./selinux/policy/file_contexts/{types.fc,program/*.fc} путь к выполняемой программе указан неправильно. В любом случае необходимо запретить выполняться процессам в домене initrc_t. Процесс администратора должен иметь тождественного пользователя и sysadm_r роль, shell и большинство его дочерних процессов будут иметь sysadm_t домен. Некоторые из выполняемых процессов одного пользователя могут быть в различных доменах, так же они требуют различных привилегий. Аналогично изменился вывод команды ls, которая теперь дополнительно показывает контекстные метки для файлов.

[root@grinder /]# ls -l –context

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

# cd policy

# su

# make relabel

Для файлов, созданных уже после установки системы, такой пользователь будет назначаться, исходя из реального идентификатора пользователя в системе (точнее, процесса, создающего файл). Так как понятие роли неприменимо к файлам, а только к пользователям (процессам), то все файлы имеют одинаковую метку-роль object_r. И файлы с различными требованиями защиты имеют различные типы, например, /boot – boot_t, а /etc имеет тип etc_t . При включении во время компиляции ядра опции SELinux Development Support система поначалу начинает функционировать в разрешающем режиме (permissive). Другими словами, вместо блокировки неразрешенных политикой защиты функций, все такие незаконные действия будут просто регистрироваться в /var/log/messages, после чего они будут разрешены. Этот режим удобно использовать для выяснения политик доступа специфичной для конкретной системы и подправить конфигурацию. Для того чтобы включить затем режим принуждения (enforcing), необходимо включить его командой avc_toggle, тогда незаконные функции будут полностью блокированы. Но самым непривычным для сисадмина будет то, что введя команду на выполнение, иногда получаем такой вот ответ от системы. Проверяем, кто мы:

[root@grinder /]# id 

Обратите внимание на роль user_r. Проверяем режим защиты:

[root@grinder /]# avc_toggle 

А теперь пробуем изменить его в разрешающий режим.

[root@grinder /]# avc_toggle

И это для root! Безобразие, однако. Все дело в том, что системный администратор должен изменить свою роль в системе, чтобы получить действительно полные права в ней.

[root@grinder /]# newrole -r sysadm_r

[oot@grinder /]# avc_toggle 

Вот теперь все нормально. Но в защищенном режиме процесс, запущенный от имени суперпользователя, не сможет получить полный доступ, как в обычной UNIX-системе. После полной отладки режимов защиты, когда определены все приложения и роли, необходимо добавить опцию «enforcing=1» в команде, передаваемой ядру при загрузке, в этом случае всегда будет возможность вернуться к отладочному режиму или для обеспечения более строгой защиты лучшим вариантом будет пересобрать ядро без Development Support, чтобы система сразу стартовала в enforcing-режиме, (но ядро с Development Support лучше всего все равно сохранить).

Управление политикой защиты

Эта тема сама по себе очень большая, на сайте проекта можно найти подробную документацию по данному вопросу, но несколько простых моментов я затрону. Все файлы политик устанавливаются в каталог /etc/security/selinux/src, если по какой-либо причине там пусто, то скопируйте все из дистрибутивного каталога ./selinux/policy в /etc/security/selinux/src. В файле «users» определены пользователи, признаваемые политикой защиты, чтобы система допускала пользователя к работе, он должен иметь запись в данном файле. В каталоге file_contexts содержится информация для маркирования каждого типа программы в системе, все программы описаны в каталоге file_contexts/program. Например, в file_contexts/program/apache.fc содержится информация, необходимая для того, чтобы распознавался веб-сервер Apache. Часть файла привожу в качестве примера.

В первой колонке с использованием регулярных выражений задаются имена файлов, а во второй содержится контекст, которым файлы соответствия должны быть помечены, обратите внимание, что роль файлов различна. Чтобы переметить заново файлы в случае, например, размещения веб-сервера в другом каталоге, изменив предварительно нужные записи, дать команду make relabel в каталоге ./selinux/policy. В подкаталоге domains содержатся записи политик защиты для каждого приложения. В domains/program содержатся макроопределения для многих известных программ. С помощью команды make load можно перестроить и перезапустить политику защиты ядра для этих файлов. Так как определение всех правил вручную – занятие долгое и требующее серьезного изучения, то самым простым способом добавить разрешающее правило (allow) будет воспользоваться скриптом scripts/newrules.pl, который автоматически обработает файл журнала на предмет недопущенных операций в разрешающем режиме работы системы. Например, когда я закомментировал строки в файле apache.te, позволяющие использовать домашние каталоги пользователей, в которых размещаются их веб-страницы. И «погонял» сервер. А затем:

Получается нечто вроде обучающегося режима. Удобно, но надо очень внимательно следить за вносимыми таким образом правилами, чтобы гарантировать, что они не расходятся с нашими целями. Но в большинстве случаев лучше все же будет определить новые домены и/или-типы, чем просто предоставить разрешение для существующего домена и/или-типа, для того чтобы сохранить гарантию безопасности. Вы можете также находить, что некоторые отрицания доступа не фатальны для применения и нет необходимости предоставления разрешения из-за общих целей защиты. Для того чтобы такие сообщения впредь не загромождали файл журнала, необходимо определить его через правило «dontaudit». При необходимости загрузки с не-SELinux ядром перед перезагрузкой выполните команду setfiles, чтобы сбросить контексты защиты файла.

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