Linux для спецслужб

Автор: Алексей Федосеев

Разработчики операционных систем любят спорить о том, какая из них надежнее и безопаснее. Особенно острыми эти споры становятся, когда речь заходит о применении системы в серьезном бизнесе или не менее серьезных государственных организациях — ставки в этих играх большие и требования — соответствующие. Медленно подбираясь к десктопу простого пользователя, Linux уже довольно уверенно себя чувствует в корпоративном и госсекторе, а в числе достоинств системы часто называют те самые «надежность и безопасность». Что же стоит за этими словами?

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

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

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

В UNIX существуют три основных права доступа: чтение, запись и «исполнение». Причем последнее трактуется по-разному для разных типов файлов. Для «обычных» файлов оно определяет возможность запуска содержащейся в нем программы[В UNIX исполняемые файлы могут иметь не только любое расширение (часто у них вообще нет точки в имени), но и содержимое — это может быть откомпилированная для данной архитектуры программа или скрипт на любом из поддерживаемых языков программирования], а для директории — право войти в нее.

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

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

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

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

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

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

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

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

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

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

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

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

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

Мандатный доступ в 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.

Cофтерринки

Автор: Илья Шпаньков

ОС: Windows, Pocket PC, Palm OS, Symbian OS

Адрес: www.lingvo.ru