Тема 2.2. Основные механизмы безопасности

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

Защита файлов от несанкционированного доступа в ОС UNIX основывается на трех фактах. Во-первых, с любым процессом, создающим файл (или справочник), ассоциирован некоторый уникальный в системе идентификатор пользователя (UID - User Identifier), который в дальнейшем можно трактовать как идентификатор владельца вновь созданного файла. Во-вторых, с каждый процессом, пытающимся получить некоторый доступ к файлу, связана пара идентификаторов - текущие идентификаторы пользователя и его группы. В-третьих, каждому файлу однозначно соответствует его описатель - i-узел.

На последнем факте стоит остановиться более подробно. Важно понимать, что имена файлов и файлы как таковые - это не одно и то же. В частности, при наличии нескольких жестких связей с одним файлом несколько имен файла реально представляют один и тот же файл и ассоциированы с одним и тем же i-узлом. Любому используемому в файловой системе i-узлу всегда однозначно соответствует один и только один файл. I-узел содержит достаточно много разнообразной информации (большая ее часть доступна пользователям через системные вызовы stat и fstat), и среди этой информации находится часть, позволяющая файловой системе оценить правомощность доступа данного процесса к данному файлу в требуемом режиме.

Общие принципы защиты одинаковы для всех существующих вариантов системы: Информация i-узла включает UID и GID текущего владельца файла (немедленно после создания файла идентификаторы его текущего владельца устанавливаются соответствующими действующим идентификатором процесса-создателя, но в дальнейшем могут быть изменены системными вызовами chown и chgrp). Кроме того, в i-узле файла хранится шкала, в которой отмечено, что может делать с файлом пользователь - его владелец, что могут делать с файлом пользователи, входящие в ту же группу пользователей, что и владелец, и что могут делать с файлом остальные пользователи. Мелкие детали реализации в разных вариантах системы различаются.

 

Тема 2.2. Основные механизмы безопасности

Разработчиками архитектуры Intel была предложена и реализована модель безопасности, основанная на так называемых «кольцах защиты» (rings), нумерующиеся от 0 до 3. 0-ое кольцо защиты не накладывает никаких ограничений на выполняемый код, на 3-ем же кольце выполняется множество проверок на правильность адресации, размерности операндов, размерности стека и т.д.

По идее разработчиков 4-ех кольцевой архитектуры, выполняемый код должен был распределяться по кольцам защиты следующим образом:

· 0-ое кольцо – ядро операционной системы;

· 1-ое кольцо – драйверы физических и виртуальных устройств, замещенные обработчики прерываний;

· 2-ое кольцо – сервисы;

· 3-е кольцо – пользовательский код.

Соответственно, была выделена группа привилегированных инструкций, для выполнения которых необходим соответствующий CPL (Code Privilege Level). Таким образом, стоит вопрос о понижении текущего CPL у выполняемого кода. Для этого существует несколько способов: механизм шлюза вызовов (callgates), возможно открытие секции физической памяти (\\Device\\PhysicalMemory) для записи и, произведя соответствующую трансляцию виртуальных адресов в физические, произвести запись нужного кода в нужный участок в верхние 2 Гб виртуальной памяти. Также имеются вполне легальные и документированные способы снижения CPL – прерывание 20h (или sysenter/syscall в WinXP и выше).

Однако, ни Unix, ни Windows ни стали использовать предложенную модель безопасности в полной мере, а используют лишь 0-ое и 3-е кольцо. При этом, на 0-ом кольце располагается ядро ОС и драйверы, а на 3-ем – сервисы и пользовательские приложения. Таким образом, стала возможна модификация непосредственно ядра операционной системы путем загрузки своего драйвера.