Защита от троянских коней

Одним из путей, с помощью которых можно обезопаситься от атак с примене­нием троянских коней, является использование безопасной операционной системы с доверительными отношениями. Один из примеров [ВОЕВ85] проиллюстрирован на рис. 15.10. В данном случае троянский конь используется для того, чтобы перехит­рить стандартный механизм безопасности, используемый большинством систем управления файлами и операционных систем — список контроля доступа. В этом примере пользователь, которого зовут Боб, взаимодействует с помощью программы с файлом данных, в котором содержится секретная символьная строка "CPE170KS". Пользователь Боб создал файл с правами чтения и записи, предоставляемыми только тем программам, которые запускаются от его имени, так что доступ к файлу могут получать только те процессы, владельцем которых является Боб.

Атака с применением троянского коня начинается тогда, когда враждебно настроенный пользователь Алиса получает законный доступ к системе и уста­навливает эту программу, а также личный файл, который будет использоваться в качестве "потайного кармана". Алиса предоставляет себе права чтения и запи­си при работе с этим файлом, а Бобу — право записи (рис. 15.10,а). Затем Алиса склоняет Боба к тому, чтобы он запустил троянского коня; для этого она, воз­можно, рекламирует программу как полезную утилиту. Когда программа обна­ружит, что ее запустил Боб, она считает из его файла секретную символьную строку и скопирует ее в потайной файл Алисы (рис. 15.10,б). Обе операции -операция чтения и операция записи — не выходят за рамки ограничений, на­кладываемых списками контроля доступа. После этого Алисе остается только за­глянуть в скопированный файл, чтобы узнать значение строки.

А теперь посмотрим, как в этой ситуации работает безопасная операцион­ная система (рис. 15.10,в). При входе пользователя в систему ее субъектам при­сваиваются уровни безопасности; при этом в качестве критерия используется терминал, с которого осуществляется доступ к компьютеру, а также идентифи­катор и пароль пользователя, которому предоставляется доступ. В рассматри­ваемом примере применяются два уровня безопасности: секретный (серый цвет) и общедоступный (белый цвет). Уровни упорядочены так, что секретный уровень выше общедоступного. Процессам и файлу данных Боба присваивается секрет­ный уровень безопасности, а файлу и процессам Алисы — общедоступный. Если Боб запускает программу-троянца (рис. 15.10,г), этой программе присваивается уровень безопасности Боба. Таким образом, она имеет возможность узнать зна­чение секретной символьной строки. Однако при попытке сохранить эту строку в общедоступном файле (потайном файле Алисы) нарушается *-свойство, и мони­тор ссылок накладывает запрет на это действие. Таким образом, попытка записи в потайной файл заканчивается неудачей, несмотря на то что она не противоре­чит списку контроля доступа: политика безопасности превосходит по старшинст­ву механизм списка управления доступом.

15.6. Безопасность операционной системы windows 2000

Хорошим примером реализации обсуждаемых концепций контроля доступа являются средства контроля доступа операционной системы Windows 2000 (W2K), в которых используются объектно-ориентированные концепции, обеспе­чивающие мощные и гибкие возможности контроля доступа.

Операционная система W2K предоставляет средства единообразного контро­ля доступа к процессам, потокам, файлам, семафорам, окнам и другим объек­там. Контролем доступа управляют два элемента: маркер доступа, который свя­зан с каждым процессом, и дескриптор защиты, связанный с каждым объектом, для которого возможно межпроцессное взаимодействие.

Схема контроля доступа

При входе пользователя система W2K использует для его аутентифика­ции схему имя/пароль. Если пользователь успешно зарегистрирован, для не­го создается процесс, с которым ассоциируется маркер доступа. Этот маркер доступа, детали которого будут описаны далее, содержит идентификатор за­щиты (security ID — SID), по которому система безопасности идентифициру­ет данного пользователя. Когда начальный пользовательский процесс порож­дает какие-нибудь другие процессы, новый объект-процесс наследует тот же маркер доступа.

Маркер доступа имеет два предназначения.

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

2. Наличие маркера доступа позволяет процессу в определенных рамках изме­нять свои характеристики безопасности, не влияя при этом на работу дру­гих процессов, запущенных от имени данного пользователя.

Основное значение второго пункта состоит в том, что маркер доступа должен иметь дело с привилегиями, которые могут быть связаны с пользова­телем. Маркер доступа указывает, какие привилегии разрешено иметь пользо­вателю. Как правило, для каждой из этих привилегий маркер инициализиру­ется состоянием запрета. Впоследствии, если одному из процессов пользовате­ля нужно выполнить привилегированную операцию, этот процесс может включить соответствующую привилегию и попытаться получить доступ. Ино­гда нежелательно хранить всю информацию по безопасности, касающуюся пользователя, в одном месте системы, потому что в этом случае предоставле­ние привилегии одному процессу приводит к тому, что данная привилегия предоставляется всем остальным процессам.

С каждым объектом, для которого возможен межпроцессный доступ, связан дескриптор защиты. Основным компонентом дескриптора защиты является спи­сок контроля доступа, в котором права доступа к данному объекту указываются для различных пользователей и для различных групп пользователей. Когда про­цесс пытается получить доступ к этому объекту, идентификатор защиты этого процесса сравнивается со списком управления доступом объекта и определяется, разрешен ли доступ.

Когда приложение открывает ссылку на подлежащий защите объект, W2K проверяет, предоставляет ли дескриптор защиты объекта доступ пользователю, которому принадлежит приложение. Если проверка проходит, система W2K по­мещает предоставленные в результате права доступа в кэш.

Важным аспектом безопасности операционной системы W2K является кон­цепция заимствования прав, упрощающая использование безопасности в среде клиент/сервер. Если клиент и сервер общаются между собой с помощью вызова удаленных процедур, сервер может временно принять параметры клиента, чтобы суметь оценить возможность доступа с правами клиента. После обработки обра­щения сервер возвращается к своему собственному состоянию.

Маркер доступа

На рис. 15.11.а показана общая структура маркера доступа, в который вхо­дят такие параметры.

• Идентификатор защиты. Уникальным образом идентифицирует пользовате­ля в рамках всех машин сети. Идентификатор защиты, как правило, соот­ветствует регистрационному имени пользователя.

• Идентификаторы защиты групп. Список групп, в которые входит пользователь. Группа — это просто набор идентификаторов пользователей, который идентифицируется при контроле доступа как группа. Каждая группа обла­дает собственным идентификатором защиты. Доступ к объекту можно опре­делять на основе группового идентификатора защиты, персонального иден­тификатора защиты или их комбинации.

• Привилегии. Список системных сервисов, важных для безопасности, к ко­торым может обратиться данный пользователь. Примером является создание маркера. Другой пример — назначение привилегий резервирования. Пользователям, обладающим этими привилегиями, разрешено пользоваться средствами создания резервных копий для резервного копирования файлов, которые им нельзя читать. Большинство пользователей не обладают ника­кими привилегиями.

Владелец по умолчанию. Если процесс создает другой объект, в данном по­ле указывается владелец нового объекта. Чаще всего пользователем нового процесса является пользователь родительского процесса. Однако пользова­тель может указать, что по умолчанию пользователем любого процесса, по­рожденного данным процессом, является идентификатор безопасности группы, к которой принадлежит пользователь.

Список контроля доступа по умолчанию. Это начальный список средств за­щиты, которые применяются к объекту, создаваемому данным пользовате­лем. Впоследствии пользователь может изменить список контроля доступа любого объекта, которым он владеет или который принадлежит группе пользователя.

Дескрипторы безопасности

На рис. 15.11,6 показана общая структура дескриптора защиты, который содержит в себе такие параметры.

• Флаги. Определяют тип и содержимое дескриптора защиты. Флаги указы­вают на наличие (или отсутствие) системного списка контроля доступа и списка разграничительного доступа, на то, помещены ли эти списки в объ­ект по умолчанию и какая адресация используется в указателях дескрипто­ра: абсолютная или относительная. Относительные дескрипторы требуются для объектов, которые передаются по сети. Примером такого объекта явля­ется информация, передаваемая при удаленном вызове процедуры,

• Владелец. Вообще говоря, владелец может выполнить с дескриптором за­ щиты любое действие. В роли пользователя может выступать индивидуальный или групповой дескриптор защиты. Владелец имеет право изменять список разграничительного контроля доступа.

• Системный список контроля доступа (System Access Control List — SACL). В этом списке указано, операции какого вида должны генерировать сооб­щения аудита. Чтобы выполнять операции чтения или записи с SACL како­го-либо объекта, приложение должно иметь соответствующие привилегии в своем маркере доступа. Это нужно, чтобы предотвратить чтение несанкцио­нированными приложениями системных списков контроля доступа (в ре­зультате чего они смогут избежать создания записей аудита), а также за­пись в них (что может привести к созданию слишком большого количества записей аудита, в которых затеряется запись о незаконной операции).

• Список разграничительного контроля доступа (Discretionary Access Control List — DACL). Определяет, какие пользователи и группы могут получить доступ к данному объекту и для каких операций. Этот список состоит из записей контроля доступа (Access Control Entry — АСЕ).

Когда создается объект, процесс-создатель может в качестве владельца на­значить этому объекту в его маркере доступа собственный идентификатор защи­ты или идентификатор защиты своей группы. Следовательно, любой процесс, которому предоставлено право изменять владельца объекта, могкет это делать, но с определенными ограничениями. Это ограничение нужно, чтобы пользова­тель не смог замести следы после того, как он попытается предпринять какие-нибудь несанкционированные действия.

Рассмотрим подробнее структуру списков контроля доступа, так как они лежат в основе средства контроля доступа операционной системы W2K (рис. 15.11,в). Каждый список состоит из общего заголовка и переменного ко­личества элементов контроля доступа. В каждом элементе указан индивиду­альный или групповой идентификатор защиты, а также маска доступа, в кото­рой определены права, которые должны быть предоставлены данному иденти­фикатору защиты. При попытке процесса получить доступ к объекту диспетчер объектов исполняющей системы W2K считывает в маркере доступа индивидуальные и групповые идентификаторы защиты, а затем просматривает список разграничительного контроля доступа объекта. Если обнаружено совпа­дение (т.е. если найден элемент контроля доступа, идентификатор защиты ко­торого совпадает с идентификатором защиты, обнаруженным в маркере досту­па), значит, этот процесс обладает правами доступа, установленными маской доступа данного элемента контроля доступа.

На рис. 15.12 показано содержимое маски доступа. В 16 младших знача­щих разрядах указываются права доступа, применяющиеся к объектам опре­деленного типа. Например, в нулевом разряде объекта-файла задается доступ по чтению, а в нулевом разряде объекта-события задается доступ для запроса статуса события.

В 16 старших разрядах маски содержатся биты, применимые к объектам всех видов.

• Синхронизация. Разрешает синхронизацию выполнения с некоторым связанным с данным объектом событием. В частности, объект может быть ис­пользован в функции ожидания.

• Разрешение на изменение владельца. Позволяет программе изменять владельца объекта. Иногда это оказывается полезным, так как владелец объек­та всегда может менять защиту своего объекта (владельцу нельзя отказы­вать в доступе для записи параметров избирательного контроля доступа).

• Разрешение на изменение списка избирательного контроля доступа. Позволяет приложению изменять DACL, меняя таким образом защиту объекта.

• Контроль чтения. Позволяет приложению обращаться к полям в дескрипторе защиты, в которых указан владелец данного объекта и его DACL.

• Разрешение на удаление. Позволяет приложению удалять объект.

Кроме того, в старшей половине маски доступа содержатся общие права досту­па четырех видов. С помощью этих битов легко устанавливать специфические права доступа к различным объектам других типов. Предположим, например, что прило­жению нужно создать объекты нескольких видов таким образом, чтобы пользовате­ли имели права доступа по чтению ко всем объектам, даже если само понятие "чтение" несколько изменяется в зависимости от типа объекта. Если бы приложению нужно было защищать каждый объект каждого вида, не используя биты общего доступа, оно должно было бы для объектов каждого вида создавать свой элемент контроля доступа, а затем аккуратно передавать его в качестве параметра при созда­нии каждого объекта. Удобнее создать один элемент контроля доступа, в котором была бы выражена общая концепция разрешения чтения, а затем просто применять этот элемент контроля доступа к каждому создаваемому объекту. В этом и состоит предназначение битов общего доступа. Перечислим эти биты:

• Generic_all — позволяет осуществлять все виды доступа;

• Generic execute — позволяет запускать исполняемые файлы;

• Generic_write — позволяет осуществлять доступ для записи;

• Generic_read — позволяет осуществлять доступ для чтения.

Значения битов общего доступа также влияют на стандартные типы досту­па. Например, для файлового объекта бит Generic_read отображается в стан­дартные биты Read_control и Synchronize, а также в специфические биты File_Read_Data, File_Read_Attributes и File_Read_EA.

Два оставшихся бита маски доступа имеют специальное значение. Бит Access_System_Security позволяет изменять контроль аудита и аварийного сигнала данного объекта. Однако недостаточно установить этот бит в элементе контроля доступа для идентификатора защиты. Кроме того, в маркере доступа процесса, обладающего этим идентификатором защиты, должна быть разрешена соответствующая привилегия.

Наконец, бит Maximum_Allowed — это не совсем бит доступа. Он изменяет алгоритм, по которому операционная система W2K сканирует список выбороч­ного контроля доступа данного идентификатора безопасности. Обычно операци­онная система W2K просматривает список выборочного контроля доступа, пока не дойдет именно до того элемента контроля доступа, который предоставляет (бит установлен) или запрещает (бит не установлен) запрашиваемый процессом доступ, или пока она не дойдет до конца списка (в этом случае доступ запре­щен). Бит Maximum__Al lowed позволяет владельцу объекта определять набор прав доступа, представляющий собой максимум того, что может быть позволено дан­ному пользователю. Помня об этом, предположим, что у приложения нет ин­формации обо всех выполняемых над объектом операциях, разрешение на кото­рые ему нужно будет просить на протяжении сеанса работы. При выполнении запроса используются три возможности.

1. Попытка открыть объект для всех возможных видов доступа. Недостаток этого подхода состоит в том, что в доступе может быть отказано, даже если приложе­ние обладает всеми правами доступа, которые нужны для этого сеанса.

2. Открытие объекта только для определенных видов доступа. При этом в объ­екте для каждого типа запроса открывается новый дескриптор, В большин­стве случаев этот метод является предпочтительным, потому что при его использовании не бывает отказов в доступе без необходимости и не предос­тавляется больше доступа, чем нужно. Однако он требует дополнительных накладных расходов.

3. Попытка открыть объект для доступа, осуществляемого в такой мере, в ка­кой это позволяет идентификатор защиты. Преимущество такого метода в том, что пользователь не получит "искусственного" отказа в доступе. Одна­ ко при этом приложение может иметь больший доступ, чем требуется. Эта ситуация может скрывать имеющиеся в приложении ошибки.

Важная особенность системы безопасности операционной системы W2K со­стоит в том, что приложение может использовать структуру безопасности этой операционной системы для объектов, заданных пользователем. Например, сервер базы данных мог бы создать свои собственные дескрипторы защиты и присоеди­нять их к блокам базы данных. В дополнение к обычным ограничениям при дос­тупе для чтения/записи сервер может позаботиться о защите таких специфиче­ских операций, выполняющихся в базе данных, как прокрутка результирующего множества или выполнение объединения. На сервер может быть возложена от­ветственность по определению значения особых прав и выполнению проверок доступа. Однако эти проверки будут выполняться в обычном контексте с исполь­зованием системных учетных записей пользователей/групп пользователей и кон­трольных журналов. Расширяемая модель безопасности может оказаться полез­ной при реализации внешних файловых систем.