Безопасный Linux

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

Comments

Серия контента:

Этот контент является частью # из серии # статей: Безопасный Linux

Следите за выходом новых статей этой серии.

Этот контент является частью серии:Безопасный Linux

Следите за выходом новых статей этой серии.

В этой статье продолжается обсуждение систем обеспечения мандатного контроля доступа для ОС 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 относится к системам мандатного контроля доступа, основанным на контроле меток (см. статью «От контроля файлового пути к расстановке меток» в разделе Ресурсы). Поэтому каждый объект или субъект в операционной системе, защищенной 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 в разделе Ресурсы).

Архитектура 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
Рисунок 1. Схема работы SELinux
Рисунок 1. Схема работы SELinux

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

Работа SELinux организована следующим образом.

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


Ресурсы для скачивания


Похожие темы


Комментарии

Войдите или зарегистрируйтесь для того чтобы оставлять комментарии или подписаться на них.

static.content.url=http://www.ibm.com/developerworks/js/artrating/
SITE_ID=40
Zone=Linux, Open source
ArticleID=643154
ArticleTitle=Безопасный Linux: Часть 1. SELinux - история появления, архитектура и принципы работы
publish-date=03242011