Журнал «Компьютерра» № 15 от 18 апреля 2006 года

Традиции UNIX

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

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

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

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

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

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

Унаследовав от 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".