Мандатный доступ в 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, — просто из-за объемности задачи. Сейчас все такие приложения приходится объединять под общим, типовым системным или пользовательским уровнем доступа, что, естественно, противоречит самой идее полного разделения служб. Однако проект постоянно совершенствуется — как с точки зрения создания и развития политик безопасности, так и через взаимодействие с разработчиками и модификацию программ.

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

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

Проект SELinux выбрался из пеленок и уверенно движется в направлении универсального средства обеспечения безопасности в Linux-системах. Вместе с другими известными открытыми разработками SELinux ведет Linux к получению высоких уровней безопасности по международным стандартам Common Criteria. Сейчас уже можно сказать, что уровень безопасности Linux-систем, особенно в вопросах организации мандатного доступа, достиг возможностей серьезных коммерческих систем. Однако основанные на Linux решения имеют преимущество перед коммерческими аналогами не только благодаря более низкой цене, но и благодаря открытости разработок и активному участию в них сообщества Open Source.

Одно из важных рыночных требований, предъявляемых к операционным системам, — их сертификация в различных организациях и комиссиях. Наиболее влиятельные международные стандарты информационной безопасности объединяются под названием общих критериев (Common Criteria). В разработке положений Common Criteria участвуют представители более чем двадцати стран, стандарты безопасности принимаются в рамках организации ISO.

В стандартах Common Criteria безопасность операционных систем рассматривается по двум «ортогональным» шкалам: по функциональным возможностям (так называемые профили защиты, Protection Profiles) и по соответствию спецификации (уровень соответствия, Assurance Levels).

В рамках того или иного профиля защиты операционная система может сертифицироваться на определенный уровень соответствия от 1 до 7 (Evaluation Assurance Level, EAL). Каждый из уровней выдвигает более жесткие требования к методам разработки и тестирования операционной системы, управлению конфигурацией, дальнейшей поддержке системы и т. п. Начиная с 4-го уровня требуется частичное предоставление исходного кода. На 7-м уровне необходимо формальное математическое доказательство безопасности системы. Сам процесс сертификации заключается в проверке аппаратно-программной платформы на соответствие указанным требованиям, проведение тестирования и анализ методов разработки системы.

Существует два профиля защиты — профиль управляемого доступа (Controlled Access Protection Profile, CAPP) и более продвинутый профиль меток доступа (Labeled Security Protection Profile, LSPP). CAPP формализует давно существующие методы организации безопасности операционных систем (начиная с UNIX и до современных ОС) — многопользовательская работа, дискреционный метод доступа, методы парольной аутентификации и т. п. LSPP расширяет CAPP, добавляя мандатный доступ, многоуровневую безопасность и контроль за импортом и экспортом информации.

Многие коммерческие UNIX-системы, а также Windows (начиная с Windows 2000) сертифицированы на уровень CAPP/EAL4. Благодаря усилиям компании IBM, операционная система Linux (точнее, дистрибутивы Red Hat Enterprise Linux и Novell SuSE) тоже сертифицирована на этот уровень. В настоящий момент ведется работа по сертификации Linux на уровень LSPP/EAL4, которого еще нет ни у одной из широко распространенных операционных систем — это стало возможно именно благодаря активному развитию проекта SELinux.

Отечественные методы сертификации безопасности операционных систем постепенно приближаются к зарубежным. С 2004 года введен стандарт ГОСТ Р ИСО/МЭК 15408 «Общие критерии оценки безопасности информационных технологий», представляющий собой перевод стандарта Common Criteria.