Безопасный Linux: Часть 1. SELinux - история появления, архитектура и принципы работы

.Введение

В этой статье продолжается обсуждение систем обеспечения мандатного контроля доступа для ОС Linux. Ранее были представлены статьи, посвященные трем крупным системам безопасности, включенным в ядро Linux: AppArmor, TOMOYO Linux, Smack. Дополнительную информацию и статьи об этих системах можно найти в разделе Ресурсы.

Начиная с этой статьи, основной темой становится Security-Enhanced Linux (или SELinux) - наиболее известный и популярный проект, посвященный защите операционных систем на базе ядра Linux от несанкционированного проникновения. В этой статье будет рассказано об истории появления SELinux, а также об архитектуре и основных принципах работы этой системы безопасности.

История SELinux

Проект разработки системы обеспечения мандатного контроля доступа Security-Enhanced Linux (SELinux) зародился в недрах Агентства национальной безопасности США (National Security Agency — NSA) (непосредственно разработкой занимались, в основном, компании Secure Computing Corporation (SCC) и MITRE, а также ряд исследовательских лабораторий) и был выпущен в свет в виде общедоступного (исходный код распространяется по лицензии GPL) программного продукта в декабре 2000 года. Это событие было отмечено специальным пресс-релизом NSA (см. п. 5 в разделе Ресурсы). К тому времени базовая архитектура SELinux разрабатывалась, изучалась и тестировалась уже около десятка лет в рамках нескольких полуисследовательских-полувоенных проектов (см. врезку «Феерия проектов: DTMach, DTOS, Fluke, Flusk, Flask»).

Новая система обеспечения мандатного контроля доступа была основана на контроле меток безопасности объектов и субъектов операционной системы и включала в себя ряд новейших технологий в области разграничения доступа. Одна из таких технологий — принудительная типизация доступа (см. врезку «Type Enforcement»), впервые опробованная в специальной спроектированной доверенной системе уровня «A1» под названием LOCK (см. врезку «LOCK»), а в дальнейшем развиваемая в подсистеме безопасности исследовательской операционной системы Flask. Использование принудительной типизации доступа позволяет, в частности, реализовать с помощью SELinux ролевой контроль доступа, многоуровневую или многокатегорийную безопасность относится к системам мандатного контроля доступа, основанным на контроле меток (см. статью «От контроля файлового пути к расстановке меток» в разделе Ресурсы). Поэтому каждый объект или субъект в операционной системе, защищенной SELinux, должен иметь свою специальную метку, называемую контекстом безопасности. Изначально такие метки хранились в виде чисел в неиспользуемых полях узлов файловой системы ext2. Каждая числовая метка отображалась SELinux как удобочитаемое текстовое название контекста безопасности. Такой подход не обладал масштабируемостью и основывался на особенностях конкретной файловой системы ext2, и потому считался очевидным недостатком всего решения.

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

Проблема, наконец, решилась с выходом серии 2.6 ядра Linux, получившей полную поддержку Linux Security Modules и расширенных атрибутов в файловой системе ext3. Для хранения меток контекста безопасности объектов и субъектов системы SELinux перешел на использование расширенных атрибутов. К сожалению, это нововведение снова привело к ограничениям, связанным с использованием файловой системы: SELinux можно было использовать только на файловых системах, имеющих поддержку расширенных атрибутов. Однако с течением времени эта проблема стала ослабевать, и сейчас уже практически все широко используемые файловые системы имеют полноценную поддержку расширенных атрибутов, а значит, могут использоваться совместно с SELinux.

Через некоторое время система безопасности SELinux была интегрирована в ядро Linux и впервые стала распространяться для тестирования в качестве подсистемы ядра 2.6.0-test3, выпущенного 8 августа 2003 года. При этом для систем с ядрами 2.2 и 2.4 система обеспечения мандатного контроля доступа выходила в виде патча к ядру, а с внедрением поддержки Linux Security Modules в ядре 2.4 была выпущена версия SELinux для LSM.

Очень быстро SELinux стал де-факто стандартом в защищенных Linux-системах и вошел в состав наиболее популярного корпоративного дистрибутива Red Hat Enterprise Linux (начиная с версии Red Hat Enterprise Linux 4). После этого SELinux стал использоваться в широко распространенных ОС Debian и Fedora и получил поддержку от набиравшего популярность дистрибутива Ubuntu (начиная с LTS-версии 8.04 Hardy Heron). Значительно позже компания Novell (разрабатывавшая в то время AppArmor и лелеявшая планы на включение его в ядро Linux) стала поддерживать SELinux в своих дистрибутивах OpenSUSE и SUSE Linux Enterprise.

В итоге, подсистема безопасности Security-Enhanced Linux получила поддержку разработчиков всех популярных дистрибутивов. В текущей ветке ядра Linux 2.6 SELinux использует для работы Linux Security Modules. Кроме того, многие элементы SELinux были включены в само ядро.

Весь этот длинный путь система обеспечения мандатного контроля доступа SELinux прошла под покровительством Агентства национальной безопасности США. Основная работа по включению системы безопасности в ядро Linux также проводилась при поддержке корпорации Red Hat. Подробный список разработчиков, внесших наиболее весомый вклад в развитие SELinux, представлен на сайте NSA (см. п. 6 в разделе Ресурсы).

--------------------------------------------------------------

Феерия проектов: DTMach, DTOS, Fluke, Flusk, Flask
В 1992-1993 гг., исследователи из NSA и SCC работали над созданием операционной системы Distributed Trusted Mach (DTMach), объединявшей результаты, полученные в рамках проектов TMach и LOCK. DTMach совмещал в себе обобщенную принудительную типизацию доступа, гибкий механизм контроля доступа и микроядро системы Mach. Проект DTMach развивался затем в рамках проекта Distributed Trusted Operating System (DTOS).

По окончании проекта DTOS усилия NSA, SCC и Университета штата Юта были объединены для интеграции архитектуры системы безопасности DTOS в исследовательскую операционную систему Fluke. Новый проект получил название Flux. Одновременно исходная архитектура системы безопасности была улучшена для предоставления лучшей поддержки динамических политик безопасности. Новая улучшенная архитектура получила название Flask. В дальнейшем эта архитектура системы безопасности была реализована NSA для ОС Linux и передана сообществу под именем Security-Enhanced Linux.

Подробнее о Flask и других упомянутых здесь проектах можно узнать на страницах сайта Университета штата Юта.

С другими разработками исследовательской группы Flux Research Group можно познакомиться по этому адресу.

--------------------------------------------------------------

Type Enforcement
Type Enforcement или принудительная типизация доступа — технология разграничения доступа, при которой права на доступ субъекта (пользователя, программного процесса и потока) к объекту (файлу, порту ввода/вывода и т.д.) даются в зависимости от текущего контекста безопасности или домена.

В SELinux контекст безопасности хранится в расширенных атрибутах файловой системы и управляется с помощью Linux security module (LSM). Принудительная типизация доступа необходима для реализации мандатного контроля доступа, дополняет ролевой контроль доступа (Role Based Access Control — RBAC) и является первым шагом к многоуровневой (Multi-Level Security — MLS) и многокатегорийной безопасности (Multi-categories security — MCS).

--------------------------------------------------------------

Linux Security Modules
Linux Security Modules (LSM) — это подсистема ядра Linux, предназначенная для интеграции в ядро различных моделей безопасности, реализованных в виде модулей.

В 2001 году на Linux Kernel Summit представители NSA предложили включить систему обеспечения мандатного контроля доступа Security-Enhanced Linux в ядро Linux версии 2.5. Однако Линус Торвальдс отклонил это предложение, из-за того, что SELinux был не единственной системой безопасности, разрабатываемой для повышения безопасности Linux. Кроме того, далеко не все разработчики были согласны с тем, что SELinux — это лучшее решение. Поэтому вместо включения SELinux в ядро напрямую, была создана система Linux Security Modules, позволяющая использовать подсистемы безопасности как модули, а значит, относительно просто подключать новые модули.

Подсистема LSM была разработана примерно за три года и включена в ядро Linux, начиная с версии 2.6. На текущий момент официально поддерживаемыми модулями безопасности являются SELinux, Apparmor, Smack и TOMOYO Linux.

Архитектура LSM подробно описана в статье «Linux Security Modules: General Security Support for the Linux Kernel», представленной на конференции USENIX Security в 2002 г.

--------------------------------------------------------------

LOCK
Целью проекта LOCK (сокращение от LOgical Coprocessing Kernel), разработанного в SCC, являлась разработка «доверенной вычислительной системы», реализующей многоуровневую безопасность. При этом система должна удовлетворять требованиям уровня «A1» согласно Trusted Computing System Evaluation Criteria (также известной как “Orange Book” - «Оранжевая книга»).

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

Основные технологии LOCK, связанные с обеспечением безопасности и разграничением доступа (в том числе и принудительная типизация доступа), развиваются теперь в следующих системах:
линейка межсетевых экранов Sidewinder Internet Firewall;
SELinux.

Более подробную информацию о проекте LOCK можно найти по этому адресу.

С момента выхода в свет, система безопасности SELinux распространялась в виде дополнений к ядрам серий 2.2 и 2.4. Однако когда встал вопрос о включении SELinux в официальное ядро, Линус Торвальдс попросил изменить проект так, чтобы подсистема безопасности Linux была реализована в виде модуля для облегчения его последующего сопровождения или усовершенствования. В результате, разработчики создали подсистему Linux Security Modules (см. врезку «Linux Security Modules»), предоставляющую интерфейс к функциям ядра для подсистемы безопасности. Такой подход позволяет пользователям и разработчикам дистрибутивов Linux выбирать между несколькими системами обеспечения мандатного контроля доступа: AppArmor, TOMOYO Linux, SMACK и SELinux.

--------------------------------------------------------------

Архитектура SELinux

Как было заявлено выше, система SELinux унаследовала архитектуру подсистемы безопасности от исследовательской операционной системы Flask. Основной особенностью Flask было использование концепции наименьших привилегий (least privilege), чтобы предоставлять пользователю или приложению только те права доступа, которые необходимы для осуществления запрошенных действий. Эта концепция реализована с помощью принудительной типизации доступа (см. врезку «Type Enforcement»), благодаря чему мандатный доступ в SELinux действует в рамках модели «домен-тип». В этой модели каждый процесс-субъект запускается в определенном контексте (домене) безопасности (то есть имеет какой-то уровень доступа), а всем ресурсам-объектам операционной системы (файлам, директориям, сокетам и пр.) ставится в соответствие определенный тип (уровень секретности).

Благодаря принудительной типизации доступа, возможности SELinux по разграничению прав значительно превосходят возможности базовой дискреционной модели доступа, используемой в UNIX-подобных системах. Например, с помощью SELinux можно строго ограничить номер сетевого порта, к которому будет обращаться сетевой сервер, можно разрешить создание и запись в отдельные файлы, но не их удаление и т.п. Такая градация объектов операционной системы позволяет ограничить системные и пользовательские процессы с помощью явно заданного набора прав доступа к конкретным ресурсам. Если какая-то из служб, контролируемых SELinux, будет взломана, злоумышленник, даже имея права суперпользователя, не сможет пробраться дальше «песочницы», ограниченной набором правил.

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

Правила имеют удобочитаемый вид и понятны даже рядовому пользователю. Например, в указанном ниже правиле для домена http-сервера разрешается чтение неких файлов, содержащих сетевую конфигурацию:allow httpd_t net_conf_t:file { read getattr lock ioctl };



Структуру и принцип работы меток, определяющих контекст безопасности объектов и субъектов операционной системы, SELinux унаследовал вместе с моделью «домен-тип» от подсистемы безопасности Flask. Для полноценной защиты, контексты безопасности должны быть определены для каждого объекта и для каждого субъекта системы. Метки имеют следующий вид:<user>:<role>:<type>



Например, распространенным контекстом безопасности является метка следующего вида: system_u:object_r:httpd_exec_t. Для SELinux пользователь system_u обычно является стандартным обозначением для демонов системы. Роль object_r назначается системным объектам типа обычных файлов или устройств. Тип httpd_exec_t применяется к исполняемому файлу httpd, расположенному по адресу /usr/sbin/httpd. Более подробно элементы «пользователь», «роль» и «тип» контекста безопасности будут обсуждаться в следующей статье.

На рисунке 1 представлена обобщенная схема обеспечения мандатного контроля доступа с помощью SELinux.

Рисунок 1. Схема работы SELinux

SELinux состоит из пяти основных компонентов: вспомогательных модулей для работы с файловой системой и для реализации взаимодействия с перехватчиком событий Linux Security Modules, основного механизма организации контроля доступа — Policy Enforcement Server, базы данных политик безопасности системы и Access Vector Cache (AVC) — вспомогательного механизма для повышения производительности.

Работа SELinux организована следующим образом.
Субъект операционной системы (процесс) пытается выполнить над определенным объектом (файлом, процессом, сокетом) некоторое действие, разрешенное в рамках стандартной дискреционной системы безопасности (DAC) Linux. Это приводит к запуску потока обращений к объекту.
Каждый запрос (обращение) на выполнение действия с объектом перехватывается модулем безопасности Linux Security Modules и вместе с контекстом безопасности субъекта и объекта передается подсистеме SELinux Abstraction & Hook Logic, отвечающей за взаимодействие с LSM.
Полученная информация от подсистемы SELinux Abstraction & Hook Logic пересылается основному модулю Policy Enforcement Server (серверу реализации политики безопасности), непосредственно ответственному за принятие решения о доступе субъекта к объекту.
Для получения решения о разрешении/запрете действия, сервер реализации политики безопасности обращается к специальной подсистеме Access Vector Cache, кэширующей наиболее часто используемые правила.
Если AVC не содержит кэшированного решения для соответствующей политики, то запрос необходимой политики безопасности перенаправляется дальше — в базу данных политик безопасности.
Найденная политика безопасности передается серверу политик, принимающему решение.
Если запрашиваемое действие удовлетворяет найденной политике, то операция разрешается. В противном случае операция запрещается, а вся информация о принятии решения записывается в лог-файл SELinux.

Помимо принятия решения о разрешении/запрете определенных действий, модуль Policy Enforcement Server отвечает также за выполнение вспомогательных задач, таких как управление метками безопасности (назначение, удаление).

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

Заключение

В представленной статье из серии «Безопасный Linux» начинается обсуждение Security-Enhanced Linux — наиболее известной и мощной системы обеспечения мандатного контроля доступа в операционных системах GNU/Linux.

SELinux заслужил славу надежной системы обеспечения безопасности. Во многом этому способствовал авторитет Агентства национальной безопасности США — основного автора и разработчика SELinux. Однако помимо авторитета NSA в основу SELinux положены многолетние научные разработки в области обеспечения информационной безопасности компьютерных систем. Эти разработки основаны на глубокой теоретической базе и прекрасно зарекомендовали себя на практике в специализированных военных системах.

Однако с использованием SELinux в корпоративных сетях и, тем более, на домашних компьютерах все не так просто. SELinux относится к системам мандатного контроля доступа, основанным на контроле меток (label-based). Это, в частности, означает, что каждому объекту и каждому субъекту операционной системы должна быть присвоена метка — контекст безопасности. В итоге, в среднем хорошая политика безопасности SELinux для всей системы содержит больше ста тысяч правил (!), так что ее создание, отладка и поддержка в актуальном состоянии отнимают чересчур много времени и сил. В реальности, создание «с нуля» такой политики безопасности для действующей или проектируемой компьютерной системы оправдано только в очень немногих случаях — если характер хранимой и обрабатываемой информации требует исключительной надежности и защищенности сервера. Злые языки говорят, что SELinux настолько непробиваем в плане информационной безопасности только из-за своей сложности — если где-то злоумышленник смог обойти защиту, то всегда можно сослаться на то, что администратор неправильно настроил SELinux.

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

Однако прогресс не стоит на месте и все эти проблемы, безусловно, привлекают пристальное внимание разработчиков. Уже создано несколько полноценных наборов правил, которые можно использовать в типовых ситуациях на серверах и домашних компьютерах. Все, что требуется от системного администратора, - выбрать одну из готовых политик безопасности и перезагрузить компьютер с включенным SELinux.

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

В следующих статьях серии «Безопасный Linux» будет подробно рассказано об использовании SELinux на практике — создании и отладке правил, контроле поведения SELinux и решении возможных проблем.

http://www.ibm.com/developerworks/ru/library/l-se_linux_01/

Обновлено: 16.03.2015