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

История операционной системы 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), вынесенные во внешний модуль. Иными словами, прежде чем выполнить какое-то действие, ядро обращается к модулю безопасности и выясняет, имеет ли право данный процесс выполнить данное действие. Таким образом, любой разработчик может реализовать какую-то специфичную политику безопасности.