Уже не первый год Linux широко используется в коммерческих и государственных организациях. Это поле диктует свои правила игры: требования к надёжности и безопасности систем очень высоки. Что предлагает Linux в ответ на этот вызов?
Традиции UNIX
История операционной системы UNIX насчитывает уже более тридцати лет. Нет ничего удивительного в том, что коммерческие и свободные реализации UNIX используются в военных и серьёзных промышленных системах. Одним из важных достоинств UNIX всегда была простота и идеологическая выдержанность. Что же касается открытости системы, то здесь у неё вообще нет равных - традиции распространения исходных кодов уходят в далёкие 1970-е. Влияние и популярность UNIX были настолько большими, что во всех современных операционных системах можно увидеть реализацию той или иной идеи из этой операционной системы.
Модель безопасности UNIX довольно проста. В основе её лежит дискреционный механизм доступа - каждый объект в системе имеет владельца, который и устанавливает права доступа к объекту. Сами пользователи в системе фигурируют в виде процессов - программ, запущенных от их имени. Так как в операционной системе UNIX даже устройства представляются в виде файлов, достаточно для каждого из них хранить владельца и права на использование этого файла другими пользователями системы.
Но в операционной системе могут работать тысячи пользователей (а такая ситуация встречается и сейчас - на мэйнфреймах и других больших машинах). При этом списки доступа (ACL, Access Control List) для каждого файла разрастутся до гигантских размеров. Частично эту проблему решает добавление групп пользователей , но ведь их число тоже может быть очень большим. Создатели UNIX придумали более элегантное решение: для каждого файла задаются три группы прав - права владельца , права группы владельца и права для всех остальных . Таким образом, все права на файл занимают лишь несколько байт.
В UNIX существует три основных права доступа: чтение, запись и исполнение. Если права чтения и записи очевидны и понятны, то право исполнения трактуется по-разному для разных типов файлов. Для простых файлов оно определяет возможность запуска содержащейся в нём программы. В UNIX исполняемые файлы могут иметь не только любое расширение (часто они вообще не имеют в имени символа точки), но и содержимое - это может быть откомпилированная для данной архитектуры программа или скрипт на любом из поддерживаемых языков программирования. А вот для директории право исполнения означает возможность "войти" в неё.
Рисунок 1. Права доступа в UNIX
Помимо комбинации из этих девяти прав доступа, каждый файл может иметь дополнительные флаги доступа: sticky-бит, специфичный для директорий, и suid-бит, применяемый для исполняемых файлов. Если пометить директорию sticky-битом, удалять файл в ней смогут только владельцы, а не все те, кто имеют права записи на эту директорию - это необходимо в "общих директориях", где создавать и удалять файлы может любой. Suid-бит - большая головная боль системных администраторов, он нужен для повышения прав программы на время запуска.
Развитие безопасности Linux
Унаследовав от UNIX традиционную модель доступа, операционная система Linux столкнулась с давно известными проблемами безопасности. Используемый в ней дискреционный метод доступа предоставляет слишком широкие возможности: любая программа, запущенная от имени пользователя, обладает всеми его правами - может читать конфигурационные файлы, устанавливать сетевые соединения и т.д.
Другой большой проблемой безопасности таких систем является наличие прав суперпользователя (или администратора). Как правило, под этим названием понимается уровень доступа системы, с которым работают все системные службы. В этом смысле, системные приложения равны в правах, хотя на самом деле каждому из них требуется "своя" часть прав суперпользователя - обращение к сетевому интерфейсу, чтение файлов с паролями, запись сообщений в системный журнал и т.п. Стоит злоумышленнику получить контроль над одной из таких служб, и ему станет доступна вся система.
Развитие операционных систем не стоит на месте. Немалую роль в достижении высокого уровня безопасности Linux сыграла открытость исходных текстов и принципы разработчиков, проповедующих использование только открытых стандартов. Вокруг Linux возникло множество проектов, предоставляющих расширенные возможности по управлению доступом. Например, ставшие стандартном де-факто встраиваемые модули аутентификации (PAM, Pluggable Authentication Modules) предоставляют гибкий, легко расширяемый механизм аутентификации пользователей.
Но в первую очередь безопасность операционной системы зависит от её ядра. Важным этапом развития ядра Linux стало внедрение интерфейса модулей безопасности (LSM, Linux Security Modules). В рамках этого проекта многие внутренние структуры ядра были расширены специальными полями, связанными с безопасностью. В код многих системных процедур были вставлены вызовы функций управления доступом (так называемые "hooks"), вынесенные во внешний модуль безопасности. Таким образом, каждый может написать собственный модуль, реализующий какую-то специфичную политику безопасности.
Рисунок 2. Модули безопасности в Linux
Формализация внешнего интерфейса управления доступом позволила многим исследовательским группам реализовать свои идеи в коде для 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 при старте системы.
Рисунок 3. Модель доступа в SELinux
Правила имеют вполне понятный вид. Например, в указанном ниже правиле для домена 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). Важной задачей при многоуровневом доступе является разработка формального механизма понижения уровня секретности документа, например по истечению срока давности.
Рисунок 4. Уровни и классы доступа в многоуровневых системах
Рисунок5. Чтение и запись информации в многоуровневых системах
Широко применяемые в военных системах обработки и хранения информации, методы мандатного и многоуровневого доступа сейчас доступны создателям коммерческих и других систем, критичных к потере информации. Но за удовольствие приходится платить - требования к подготовке администраторов таких систем значительно выше, а архитекторам необходимо заранее и чётко проработать политику безопасности.
Сертификация безопасности 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 решения превосходят коммерческие аналоги не только низкой ценой, но и принципами открытой разработки и активного участия сообщества.