Журнал «Компьютерра» № 15 от 18 апреля 2006 года
Шрифт:
Правила имеют вполне понятный вид. Например, в указанном ниже правиле для домена 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-м уровне необходимо формальное математическое доказательство безопасности системы. Сам процесс сертификации заключается в проверке аппаратно-программной платформы на соответствие указанным требованиям, проведение тестирования и анализ методов разработки системы.