Защита информации всегда очень беспокоила военных. Именно в недрах министерств обороны родились первые критерии и стандарты безопасности программ и операционных систем. В числе подобных изобретений и так называемый мандатный доступ (Mandatory Access Control, MAC). Уже привычный нам дискреционный способ (Discretionary Access Control, DAC) подразумевает установку прав доступа к файлу его владельцем, тогда как при мандатном подходе политика доступа к информации задается независимо от пользователей системы и не может быть изменена во время работы системы.
Понятие мандатного доступа часто совмещают с понятием многоуровневой системы доступа (Multilevel Security, MLS). В рамках этой модели безопасности фигурируют объекты (пассивные сущности) и субъекты (активные сущности): каждому объекту соответствует уровень секретности (например, знакомые любому слова «секретно» или «совершенно секретно»), а субъекту — уровень доступа. Обычно в таких системах присутствует и классификация информации по ее тематике. Система безопасности должна обеспечивать доступ к соответствующим уровням и классам, а также невозможность чтения более высоких уровней секретности и запись в объекты с более низким уровнем секретности (чтобы не допустить утечку информации). Этот подход реализуется в одной из самых распространенных моделей в рамках многоуровневого доступа — модели Белла-Ла Падулы (Bell-La Padula). Важной задачей при многоуровневом доступе является разработка формального механизма понижения уровня секретности документа, например по истечении срока давности.
Методы мандатного и многоуровневого доступа, широко применяемые в военных системах обработки и хранения информации, сейчас доступны создателям коммерческих и других систем, критичных к потере информации. Но за удовольствие приходится платить — требования к подготовке администраторов таких систем значительно выше, а архитекторам необходимо заранее и четко проработать политику безопасности.
Подробнее о достоинствах и недостатках системы многоуровневого доступа и мандатного метода доступа можно узнать из работы Ричарда Смита "Introduction to Multilevel Security".
SELinux — это расширение базовой модели безопасности операционной системы Linux, добавляющее механизм мандатного доступа (см. врезку). С помощью SELinux можно задать явные правила, согласно которым субъекты (пользователи и программы) должны обращаться к объектам системы (файлы и устройства). Таким образом, можно ограничить программы, прописав возможности их поведения в виде политики, и возложив ответственность за ее соблюдение на операционную систему.
SELinux входит в официальное ядро Linux начиная с версии 2.6. Систему разрабатывает Национальное агентство по безопасности США (National Security Agency, NSA) при сотрудничестве с другими исследовательскими лабораториями и коммерческими дистрибутивами Linux. Исходные тексты проекта доступны под лицензией GPL.
Мандатный доступ в SELinux реализован в рамках модели домен-тип. В этой модели каждый процесс запускается в определенном домене безопасности (то есть имеет какой-то уровень доступа), а всем ресурсам (файлам, директориям, сокетам и пр.) ставится в соответствие определенный тип (уровень секретности). Список правил, ограничивающих возможности доступа доменов к типам, и составляет политику. Он задается один раз в момент установки системы и представляет собой набор текстовых файлов, которые могут быть скомпилированы и загружены в память ядра Linux при старте системы.
Правила имеют вполне понятный вид. Например, в указанном ниже правиле для домена http-сервера разрешается чтение неких файлов, содержащих сетевую конфигурацию:
allow httpd_t net_conf_t:file { read getattr lock ioctl };
Возможности SELinux по управлению доступом значительно превосходят возможности базовых прав UNIX. Например, можно строго ограничить номер сетевого порта, к которому будет привязываться ваш сетевой сервер, или разрешить создание и запись в файлы, но не их удаление. Это позволяет ограничить системные службы с помощью явно заданного набора существующих прав. Даже если какая-то из таких служб будет взломана, злоумышленник, имея права суперпользователя, не сможет пробраться дальше заданных ограничений.
Конкуренцию SELinux может составить проект RSBAC, реализующий мандатный и ролевой механизмы доступа. Начавшись намного раньше SELinux, проект RSBAC уже в 2000 году достиг стабильного состояния. Разработчики гордятся тем, что совершенно не зависят от правительственных организаций и больших компаний, — их код написан «с нуля».
На самом деле, RSBAC — это среда для создания и использования различных моделей доступа. В ее рамках уже разработаны несколько модулей — продвинутые мандатный и ролевой механизмы и простое расширение списков доступа. С теоретической точки зрения эта работа основывается на публикации Абрамса и Ла Падулы «Generalized Framework for Access Control» («Обобщенная среда для управления доступом»).
Помимо привычного администратора в операционную систему добавляется администратор безопасности, который может ограничить всех пользователей (в том числе и суперпользователя) в доступе к информации. Это создает лишний уровень привилегий на пути злоумышленника к полному контролю над системой, но возлагает большую ответственность на администратора безопасности.
Функциональность RSBAC достаточно велика, с его помощью можно добиться таких интересных эффектов, как организация доступа к файлу только в определенные часы. Но явно ощущаются недостаток документации, небольшое количество разработчиков и пользователей системы.
RSBAC распространяется под лицензией GPL и представляет собой набор патчей к текущему ядру Linux. В отличие от SELinux, в основную ветку ядра Linux RSBAC не входит — сказываются меньшие активность и финансирование проекта. Ряд дистрибутивов GNU/Linux поддерживает RSBAC, в частности Hardened Gentoo и отечественный ALT Linux Castle.
SELinux уже давно вышел за рамки исследовательского проекта. Ряд дистрибутивов GNU/Linux (Red Hat/Fedora, SuSE 9, Gentoo, Debian) включают преконфигурированный вариант системы. Наиболее развита поддержка SELinux в дистрибутивах Red Hat (чего только стоит созданное ими полноценное руководство по всем аспектам работы и администрирования SELinux).
В среднем политика безопасности SELinux для всей системы содержит больше ста тысяч правил, так что ее создание и отладка отнимают много времени. Однако уже разработано несколько готовых политик, которые можно использовать в типовых ситуациях на серверах и даже домашних компьютерах. Все, что требуется от системного администратора, — выбрать одну из них и перезагрузить компьютер с включенным SELinux.
При попытке создать правила доступа для какой-либо программы разработчик или администратор может столкнуться с тем, что она не была написана с учетом ограничений SELinux. Например, некоторые приложения под UNIX практикуют частый переход от прав суперпользователя к правам простого пользователя и обратно (права суперпользователя фактически используются только там, где это действительно необходимо) — такое поведение в рамках модели безопасности SELinux описать непросто.
Многие проекты (например, штатный файрволл Linux, называемый IPTables) еще полноценно не включены в модель доступа SELinux. Так же, как и графическое окружение KDE, — просто из-за объемности задачи. Сейчас все такие приложения приходится объединять под общим, типовым системным или пользовательским уровнем доступа, что, естественно, противоречит самой идее полного разделения служб. Однако проект постоянно совершенствуется — как с точки зрения создания и развития политик безопасности, так и через взаимодействие с разработчиками и модификацию программ.