SELinux: теория и практика безопасности

Традиции UNIX

История операционной системы UNIX насчитывает уже более тридцати лет. Нет ничего удивительного в том, что коммерческие и свободные реализации UNIX используются в военных и серьёзных промышленных системах. Одним из важных достоинств UNIX всегда была простота и идеологическая выдержанность. Что же касается открытости системы, то здесь у неё вообще нет равных - традиции распространения исходных кодов уходят в далёкие 1970-е. Влияние и популярность UNIX были настолько большими, что во всех современных операционных системах можно увидеть реализацию той или иной идеи из этой операционной системы.

Модель безопасности UNIX довольно проста. В основе её лежит дискреционный механизм доступа - каждый объект в системе имеет владельца, который и устанавливает права доступа к объекту. Сами пользователи в системе фигурируют в виде процессов - программ, запущенных от их имени. Так как в операционной системе UNIX даже устройства представляются в виде файлов, достаточно для каждого из них хранить владельца и права на использование этого файла другими пользователями системы.

Но в операционной системе могут работать тысячи пользователей (а такая ситуация встречается и сейчас - на мэйнфреймах и других больших машинах). При этом списки доступа (ACL, Access Control List) для каждого файла разрастутся до гигантских размеров. Частично эту проблему решает добавление групп пользователей, но ведь их число тоже может быть очень большим. Создатели UNIX придумали более элегантное решение: для каждого файла задаются три группы прав - права владельца, права группы владельца и права для всех остальных. Таким образом, все права на файл занимают лишь несколько байт.

В UNIX существует три основных права доступа: чтение, запись и исполнение. Если права чтения и записи очевидны и понятны, то право исполнения трактуется по-разному для разных типов файлов. Для простых файлов оно определяет возможность запуска содержащейся в нём программы. В UNIX исполняемые файлы могут иметь не только любое расширение (часто они вообще не имеют в имени символа точки), но и содержимое - это может быть откомпилированная для данной архитектуры программа или скрипт на любом из поддерживаемых языков программирования. А вот для директории право исполнения означает возможность "войти" в неё.

Помимо комбинации из этих девяти прав доступа, каждый файл может иметь дополнительные флаги доступа: sticky-бит, специфичный для директорий, и suid-бит, применяемый для исполняемых файлов. Если пометить директорию sticky-битом, удалять файл в ней смогут только владельцы, а не все те, кто имеют права записи на эту директорию - это необходимо в "общих директориях", где создавать и удалять файлы может любой. Suid-бит - большая головная боль системных администраторов, он нужен для повышения прав программы на время запуска.

Развитие безопасности Linux

Унаследовав от UNIX традиционную модель доступа, операционная система Linux столкнулась с давно известными проблемами безопасности. Используемый в ней дискреционный метод доступа предоставляет слишком широкие возможности: любая программа, запущенная от имени пользователя, обладает всеми его правами - может читать конфигурационные файлы, устанавливать сетевые соединения и т.д.

Другой большой проблемой безопасности таких систем является наличие прав суперпользователя (или администратора). Как правило, под этим названием понимается уровень доступа системы, с которым работают все системные службы. В этом смысле, системные приложения равны в правах, хотя на самом деле каждому из них требуется "своя" часть прав суперпользователя - обращение к сетевому интерфейсу, чтение файлов с паролями, запись сообщений в системный журнал и т.п. Стоит злоумышленнику получить контроль над одной из таких служб, и ему станет доступна вся система.

Развитие операционных систем не стоит на месте. Немалую роль в достижении высокого уровня безопасности Linux сыграла открытость исходных текстов и принципы разработчиков, проповедующих использование только открытых стандартов. Вокруг Linux возникло множество проектов, предоставляющих расширенные возможности по управлению доступом. Например, ставшие стандартном де-факто встраиваемые модули аутентификации (PAM, Pluggable Authentication Modules) предоставляют гибкий, легко расширяемый механизм аутентификации пользователей.

Но в первую очередь безопасность операционной системы зависит от её ядра. Важным этапом развития ядра Linux стало внедрение интерфейса модулей безопасности (LSM, Linux Security Modules). В рамках этого проекта многие внутренние структуры ядра были расширены специальными полями, связанными с безопасностью. В код многих системных процедур были вставлены вызовы функций управления доступом (так называемые "hooks"), вынесенные во внешний модуль безопасности. Таким образом, каждый может написать собственный модуль, реализующий какую-то специфичную политику безопасности

Формализация внешнего интерфейса управления доступом позволила многим исследовательским группам реализовать свои идеи в коде для Linux. При этом серьёзную роль в улучшении безопасности Linux сыграли и коммерческие компании. Например, компания IBM активно участвует в совершенствовании безопасности Linux и других открытых проектов. Также большая заслуга принадлежит создателям дистрибутивов - как коммерческих (в первую очередь, Red Hat и Novell), так и некоммерческих, например проект Hardened в рамках дистрибутива Gentoo.

Существует несколько серьёзных проектов по расширению стандартной модели безопасности в Linux. Среди них можно выделить SELinux (Security-Enhanced Linux), RSBAC (Rule Set Base Access Control) и grsecurity. В этой статье рассматривается проект SELinux, который не только позволяет повысить уровень защищённости обычной Linux-системы, но и даёт возможность реализации более сложных моделей безопасности.

Что такое SELinux

SELinux - это расширение базовой модели безопасности операционной системы Linux, добавляющее механизм мандатного доступа. С помощью SELinux можно задать явные правила того, как субъекты (пользователи и программы) могут обращаться к объектам системы (файлы и устройства). Таким образом, можно ограничить программы, прописав возможности их поведения в виде политики, а операционная система обеспечит её соблюдение.

SELinux входит в официальное ядро Linux начиная с версии 2.6. Система разрабатывается Национальным агентством по безопасности США (NSA, National Security Agency) при сотрудничестве с другими исследовательскими лабораториями и коммерческими дистрибутивами Linux. Исходные тексты проекта доступны под лицензией GPL.

Мандатный доступ в SELinux реализован в рамках модели домен-тип. В этой модели каждый процесс запускается в определённом домене безопасности (уровень доступа), а всем ресурсам (файлы, директории, сокеты и т.п.) ставится в соответствие определённый тип (уровень секретности). Список правил, ограничивающих возможности доступа доменов к типам, называется политикой и задаётся один раз в момент установки системы. Описание политики в SELinux - это набор текстовых файлов, которые могут быть скомпилированы и загружены в память ядра Linux при старте системы.

Правила имеют вполне понятный вид. Например, в указанном ниже правиле для домена http-сервера разрешается чтение неких файлов, содержащих сетевую конфигурацию.

allow httpd_t net_conf_t:file { read getattr lock ioctl };

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

Что получает системный администратор

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

Мандатный доступ

Защита информации всегда очень волновала военных. Именно в недрах министерств обороны возникли первые критерии и стандарты безопасности программ и операционных систем. В числе таких изобретений и метод доступа к информации, именуемый мандатным доступом (MAC, Mandatory Access Control). Уже привычный нам дискреционный способ (DAC, Discretionary Access Control) подразумевает установку прав доступа к файлу его владельцем. Тогда как при мандатном подходе политика доступа к информации задаётся не зависимо от пользователей системы и не может быть изменена в ходе работы системы.

Часто понятие мандатного доступа совмещают с понятием многоуровневой системы доступа (MLS, Multilevel security). В рамках этой модели безопасности фигурируют объекты (пассивные сущности) и субъекты (активные сущности): каждому объекту соответствует уровень секретности (например, знакомые любому слова "секретно" или "совершенно секретно"), а субъекту - уровень доступа. Обычно в таких системах присутствует и классификация информации по её тематике. Система безопасности должна обеспечивать доступ к соответствующим уровням и классам, а также невозможность чтения более высоких уровней секретности и запись в объекты с более низким уровнем секретности (чтобы не допустить утечку информации). Это подход реализуется в одной из самых распространённых моделей в рамках многоуровневого доступа - модели Белла-Ла Падула (Bell-La Padula). Важной задачей при многоуровневом доступе является разработка формального механизма понижения уровня секретности документа, например по истечению срока давности.

Широко применяемые в военных системах обработки и хранения информации, методы мандатного и многоуровневого доступа сейчас доступны создателям коммерческих и других систем, критичных к потере информации. Но за удовольствие приходится платить - требования к подготовке администраторов таких систем значительно выше, а архитекторам необходимо заранее и чётко проработать политику безопасности.

Подробнее про достоинства и недостатки системы многоуровневого доступа и мандатного метода доступа можно узнать из работы Ричарда Смита - Introduction to Multilevel Security.

Сертификация безопасности Linux

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

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

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

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

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

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

RSBAC

Конкуренцию SELinux может составить проект RSBAC, реализующий мандатный и ролевой механизмы доступа. Начавшись намного раньше, проект RSBAC уже в 2000 году достиг стабильного состояния. Разработчики гордятся тем, что совершенно не зависят от правительственных организаций и больших компаний, написав весь код с нуля.

На самом деле, RSBAC - это среда для создания и использования различных моделей доступа. В её рамках уже разработаны несколько модулей - продвинутые мандатный и ролевой механизмы и простое расширение списков доступа. С теоретической точки зрения эта работа основывается на публикации Абрамса и Ла Падула Обобщённая среда для управления доступом (GFAC, Generalized Framework for Access Control).

Помимо привычного администратора в операционную систему добавляется администратор безопасности, который может ограничить всех пользователей (в том числе и суперпользователя) в доступе к информации. Это создаёт лишний уровень привилегий на пути злоумышленника к полному контролю над системой, но возлагает большую ответственность на администратора безопасности.

Функциональность RSBAC достаточно велика, с его помощью можно добиться таких интересных эффектов, как организация доступа к файлу только в определённые часы. Но явно ощущаются недостаток документации, небольшое количество разработчиков и пользователей системы.

RSBAC распространяется под лицензией GPL и представляет собой набор патчей к текущему ядру Linux. В отличие от SELinux, в основную ветку ядра Linux RSBAC не входит - сказываются меньшие активность и финансирование проекта. Ряд дистрибутивов GNU/Linux поддерживает RSBAC, можно отметить Hardened Gentoo и отечественный ALT Linux Castle.

Заключение

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

Обновлено: 16.03.2015