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