Реферат: Реферат по дисциплине «Информационная безопасность» Тема: «Вопросы корректности реализации механизмов защиты от нсд добавочными средствами»

Федеральное агентство по образованию РФ


Российский государственный университет инновационных технологий и предпринимательства (РГУИТП)

Северный филиал


Реферат по дисциплине

«Информационная безопасность»


Тема: «Вопросы корректности реализации механизмов защиты от НСД добавочными средствами»

















^ Выполнил студент группы И411

______________ И.И. Попов

"____"_________ 2008 г.



Великий Новгород


Введение

В данном реферате рассмотрены вопросы корректности реализации средств добавочной защиты от несанкционированного доступа (СЗИ НСД). Актуальность подобного исследования, обусловливается следующими двумя причинами. Во-первых, СЗИ НСД, призванные наделять систему новыми свойствами защиты, при некорректной их реализации, могут вносить собственные уязвимости, причем последствия от внесения подобных уязвимостей могут быть куда более значимы, чем положительный эффект, связанный с реализацией новых свойств защиты. Поэтому потребитель, приобретая добавочную СЗИ НСД, должен обладать информацией, достаточной, чтобы быть уверенным в корректности ее реализации. Во-вторых, несмотря на то, что требования к корректности реализации СЗИ НСД определены в соответствующих нормативных документах, вполне естественно то, что в подобных документах не может быть представлена подробная детализация требований, учитывающая специфику реализации конкретного программного средства, в частности ОС (в противном случае, под каждую ОС, а в общем случае, и под каждую версию ОС одного семейства, должен был бы быть свой документ, регламентирующий требования к механизмам защиты). Тогда возникает вопрос достаточности, а также проблема трактовки требований разработчиками и потребителями СЗИ НСД в каждом конкретном случае – с учетом особенностей архитектурной реализации системного средства, как следствие, вопрос о необходимости дополнительных уточняющих требований к корректности реализации СЗИ НСД для конкретных ОС и их версий.

^ Формализованные требования к механизмам защиты.

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

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

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

Здесь будет рассмотрен, наиболее важный механизм - управления доступом к ресурсам. Поскольку номенклатура защищаемых ресурсов достаточно велика (файловые объекты, объекты реестра ОС, устройства, сетевые ресурсы и т.д.), ограничимся рассмотрением только задач управления доступом к файловым объектам (естественно, далее будем говорить о файловой системе NTFS). С учетом возможности реализации альтернативных моделей контроля доступа к файловым объектам (наиболее распространены схемы избирательного и полномочного контроля доступа) рассмотрим только избирательное управление (еще его называют дискреционным доступом, однако этот термин требует некоторого уточнения), с учетом того, что требования к реализации данного механизма в СЗИ НСД регламентируются для средства вычислительной техники (СВТ), начиная уже с шестого класса защищенности (т.е. должны выполняться по существу любой СЗИ НСД).

Таким образом, в данной работе, на конкретном примере исследования только одного механизма защиты, предлагается рассмотреть, одну из ключевых проблем создания средств добавочной защиты. При этом отметим, что объектом исследования являются ни в коей мере не конкретные реализации СЗИ НСД, а лишь собственно требования к механизмам защиты и известные (опубликованные) архитектурные особенности рассматриваемой ОС, представляющие для нас интерес, в части проводимого нами анализа формализованных требований, применительно к конкретному системному ПО.

Приведем формализованные базовые требования (к СВТ шестого класса защищенности) к рассматриваемому в работе механизму защиты, в соответствии с действующим сегодня нормативным документом, которые в установлены для дискреционного принципа контроля доступа:

КСЗ должен контролировать доступ наименованных субъектов (пользователей) к наименованным объектам (файлам, программам, томам и т.д.).

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

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

Контроль доступа должен быть применим к каждому объекту и каждому субъекту (индивиду или группе равноправных индивидов).

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

Право изменять ПРД должно предоставляться выделенным субъектам (администрации, службе безопасности и т.д.).

Это, как раз и есть те общие формализованные требования (видим, что в них нет никаких ссылок на тип и версию системного ПО) в части исследования вопросов целесообразности их уточнения с учетом архитектурных особенностей системного ПО, в нашем случае – ОС Windows (технологии NT, файловая система NTFS).

^ Анализ этих требований.

Естественно, что требование: «КСЗ должен содержать механизм, претворяющий в жизнь дискреционные правила разграничения доступа» собственно и определяет дискреционный принцип контроля доступа (задает, что должна быть реализована схема избирательного, а не полномочного управления доступом).

Требование: «КСЗ должен контролировать доступ наименованных субъектов (пользователей) к наименованным объектам (файлам, программам, томам и т.д.)» важно в той части, что если субъект всегда наименован (любое обращение к файловому объекту характеризуется SID, в частности, именем пользователя, от лица которого осуществляется обращение к ресурсу), то информация может, храниться как в файловом объекте, который всегда может быть идентифицирован (иначе к нему не осуществить доступ штатными средствами), так и не обладать идентифицирующими признаками – это, так называемая, остаточная информация (информация, остающаяся на носителе после удаления или модификации файлового объекта штатными средствами). Доступ к остаточной информации можно получить средствами, так называемого, прямого доступа к памяти. Данное требование задает, что подобная задача защиты от НСД уже не является функцией дискреционного принципа контроля доступа (в соответствующих нормативных документах, начиная с СВТ пятого класса, данная задача защиты возлагается на отдельный механизм защиты - очистка памяти: «При первоначальном назначении или при перераспределении внешней памяти КСЗ должен предотвращать доступ субъекту к остаточной информации»).

Рассматривая требования, прежде всего, остановимся на кажущемся противоречии двух из них: «КСЗ должен содержать механизм, претворяющий в жизнь дискреционные правила разграничения доступа» и «Право изменять ПРД должно предоставляться выделенным субъектам (администрации, службе безопасности и т.д.)». Поясним суть возможной противоречивой трактовки данных требований.

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

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

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

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

^ Реализация требований

Итак, разобравшись в этом вопросе, рассмотрим, как же необходимость выполнения требования: «Право изменять ПРД должно предоставляться выделенным субъектам (администрации, службе безопасности и т.д.)» сказывается на реализации дискреционного механизма управления доступом к файловым объектам для ОС Windows – какие уточняющие требования к его реализации могут быть сформулированы.

В разграничительной политике доступа к ресурсам, соответственно, и в схеме управления доступом не должно присутствовать сущности «Владелец» как таковой. Таким образом, субъектов доступа будем делить на пользователей (не обладающими никакими правами владения и какими-либо правами назначать и изменять ПРД) и администраторов, обладающих правом назначать (изменять) ПРД. Как следствие, механизм защиты не должен содержать сущности «Владелец», атрибутов доступа, связанных с исключаемой сущностью «Владелец», и возможностей назначения (изменения) остальных атрибутов пользователями.

Основным объектом доступа, для которого устанавливаются ПРД администратором, является папка (диск, каталог, подкаталог). Это вызвано тем, что администратор не может устанавливать разграничения для всех вновь создаваемых пользователями файлов. Отсюда следует, во-первых, что СЗИ НСД должна обладать возможностью устанавливать основные значимые атрибуты доступа (чтение, запись, исполнение) на папку, во-вторых, по умолчанию права доступа должны наследоваться файловыми объектами, включаемыми в папку, для которой администратором заданы ПРД, в-третьих, ПРД по разрешениям типов доступа для включающего объекта должны быть приоритетнее(именно они должны действовать) ПРД по разрешениям для включаемого объекта.

В качестве замечания остановимся на некоторых рекомендациях по реализации механизма защиты, следующих из сформулированных выше требований, которые, следует иметь в виду разработчикам СЗИ НСД.

Обратимся к требованию: «Для каждой пары (субъект - объект) в СВТ должно быть задано явное и недвусмысленное перечисление допустимых типов доступа (читать, писать и т.д.), т.е. тех типов доступа, которые являются санкционированными для данного субъекта (индивида или группы индивидов) к данному ресурсу СВТ (объекту)». Здесь можно отметить следующее – несомненно все типы запросов механизм должен перехватывать, однако возникает вопрос, какой набор атрибутов доступа следует выносить в интерфейс СЗИ НСД – для их назначения (изменения) администратором, а какие атрибуты СЗИ НСД должна устанавливать автоматически, исходя из иных установленных атрибутов. Поясним сказанное. Например, для задания разграничительной политики (настройки механизма) можно использовать лишь три основных атрибута (запись, чтение, исполнение), остальные же значимые атрибуты (например, обзор, создание, удаление, переименование) могут устанавливаться СЗИ НСД по умолчанию, в частности, по следующей схеме. Пользователю разрешается обзор объектов, включающих разрешенный ему для доступа объект (например, если пользователю разрешается доступ к каталогу D:\User1\, ему разрешается обзор диска D:\, а на диске D:\ только каталога D:\User1), пользователю разрешается создание, удаление, переименование объектов (естественно, при разрешении «на запись»), включаемых в разрешенный объект и не разрешаются подобные действия с включающим объектом (например, при разрешении доступа «на запись» в каталог D:\User1\, пользователь может создавать, удалять, переименовывать объекты в этом каталоге, но не может создавать, удалять, переименовывать объекты на диске D:\, соответственно, если объектом разграничения является файл, например, D:\User1\fail, пользователь не может удалять, переименовывать этот файл и создавать новые файлы в этом каталоге). На самом деле, проблема минимизации числа атрибутов доступа, выносимых в интерфейс СЗИ НСД, для их задания администратором, крайне важная задача. Это подтверждается тем, что в современной статистике успешных атак на защищаемые ресурсы, уязвимости системы, обусловливаемые ошибками администрирования, имеют весьма значительную долю [3-4]. Поэтому, достоинством СЗИ НСД является именно обоснованная минимизация числа атрибутов доступа, выносимых в интерфейс, а не максимальное их представление в интерфейсе, с целью реализации, яко бы «тонких» настроек механизма (опять же встает задача обоснования необходимости и достаточности атрибутов, выносимых для настройки механизма в интерфейс).

В части упрощения задачи администрирования, что автор считает крайне важным, остановимся еще на одной проблеме. При назначении (изменении) ПРД стоит задача назначить атрибуты доступа, реализующие права пользователей на доступ к файловым объектам. Современными ОС это реализуется следующим образом – для объекта устанавливается – какие субъекты и по каким правилам могут к нему общаться. Но возможен и иной подход – можно назначать субъектам – к каким объектам и по каким правилам они могут обращаться. Это в корне меняет как собственно интерфейс настройки механизма, так и возможность установки атрибутов «по умолчанию» СЗИ НСД (меняется и сама схема хранения и обработки атрибутов при анализе запроса доступа). Здесь отметим, что во втором случае не только упрощается администрирование, причем, как в части интуитивной понятности интерфейса (права доступа, на основании которых уже и формируемые ПРД, определяются для пользователей, а не для объектов), так и в части минимизации действий (записей), производимых администратором при задании (изменении) ПРД, но и достигается выполнение требования к индуктивности модели безопасности (об этом речь пойдет ниже). По понятным причинам в ОС атрибуты присваиваются объектам – это обусловлено, как способом хранения атрибутов (например, в NTFS), так и включением в схему управления доступом сущности «Владелец» (при назначении (изменении) прав доступа к созданному файлу владелец может назначать (изменять) атрибуты файла, которым владеет, но никак не общие ПРД, установленные для другого пользователя). Для СЗИ НСД, как отмечали, сущности «Владелец» вообще не должно быть, а назначенные ПРД при любом случае из задания будут храниться в отдельном объекте (например, в файле(ах) настроек механизма).

Пример интерфейса, реализующий данные подходы к настройке механизма в КСЗИ «Панцирь» для ОС Windows 2000/XP/2003, приведен на рис.3.1



Продолжим свои исследования, для чего вновь вернемся к рассмотрению требования: «Для каждой пары (субъект - объект) в СВТ должно быть задано явное и недвусмысленное перечисление допустимых типов доступа (читать, писать и т.д.), т.е. тех типов доступа, которые являются санкционированными для данного субъекта (индивида или группы индивидов) к данному ресурсу СВТ (объекту)», а также тесно связанного с ним требования: «Контроль доступа должен быть применим к каждому объекту и каждому субъекту (индивиду или группе равноправных индивидов)». С этими требованиями связаны основные условия корректности реализации механизма, причем, как в общем случае, так и применительно к конкретной ОС. Прежде всего, из требования: «КСЗ должен контролировать доступ наименованных субъектов (пользователей) к наименованным объектам (файлам, программам, томам и т.д.)» уточним, что под субъектом доступа здесь понимается пользователь.

Прежде всего, можно видеть, что из рассмотренных требований логично вытекает требование к индуктивности модели безопасности (напомним, что модель безопасности принято называть индуктивной, если для системы, однажды установленной в безопасное состояние, гарантируется нахождение системы в безопасном состоянии в последующие моменты времени).

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

ПРД может назначать (изменять) только администратор (сущность “Владелец” исключается), как следствие, пользователь не может изменить ПРД в процессе функционирования системы;

Основной реализации разграничительной политики доступа к ресурсам является разрешительная разграничительная политика доступа: «Все, что не разрешено (явно не указано), то запрещено». В этом случае к любому объекту, для которого не заданы разграничения, в том числе и к вновь создаваемому объекту не в папке, на которую установлены разграничения, «по умолчанию» будет запрещен какой-либо доступ всем пользователям. Как следствие, основными атрибутами доступа будут: «Ресурсы, разрешенные для чтения», «Ресурсы, разрешенные для записи», «Ресурсы, разрешенные для исполнения» (см. рис.3.1).

Продолжая данную тему, остановимся, на крайне важном моменте – рассмотрим требования к дискреционному принципу контроля доступа в случае его совместного использования с мандатным принципом контроля доступа (начиная с СВТ четвертого класса защищенности СВТ, в соответствии с [ 1 ]). Заметим, что следуя [ 1 ], базовые требования к дискреционному контролю доступа здесь те же, что рассматривались нами выше (они несколько дополнены, но об этом поговорим далее). Однако, здесь возникают следующие вопросы – обоими этими принципами в их трактовке, представленной в [ 1 ], задаются требования к реализации индуктивной модели безопасности – насколько это оправдано и к чему приводит? Рассмотрим, в чем состоят особенности реализации дискреционного принципа контроля доступа в данных приложениях. Во-первых, модель полномочного управления доступом (на основе меток безопасности, или, как называют, мандатное управление), априори являющаяся индуктивной, является частным случаем индуктивной модели дискреционного управления, что не сложно строго доказать (подобным дискреционным механизмом можно реализовать все возможности, с учетом основного назначения полномочного управления – не допустить снижения мандатного механизма, т.к. в обоих случаях реализуется принудительное управление [ 2 ]), и его преимущество перед дискреционным в этом случае состоит лишь в упрощении задачи администрирования, за счет использования меток. Во-вторых, одновременное использование мандатного механизма (который разграничивает доступ не между субъектами и объектами, а между категориями субъектов и объектов) и дискреционного уже предполагает реализацию дискреционным механизмом запретительной разграничительной политики доступа: «Все, что не запрещено (явно не указано), то разрешено» (в противном случае при настройке дискреционного механизма потребуется повторить все разграничения, заданные для мандатного механизма, и еще внести дополнительные разграничения для субъектов и объектов внутри категорий, т.е. не о каком упрощении администрирования в этом случае уже речь не идет, а применение мандатного механизма при этом становится просто бессмысленным – только усложняет задачу администрирования). Заметим, что для СВТ, использующих полномочное управление доступа, именно мандатный механизм призван обеспечивать индуктивность модели безопасности, являясь здесь первичным, дискреционный же механизм реализуется в дополнение к мандатному, с целью разграничения доступа внутри категории.

Сказанное выше также можно рассматривать, как весьма важное уточняющее требование.

Пример интерфейса настроек дискреционного механизма, реализованного в КСЗИ «Панцирь» для ОС Windows 2000/XP/2003 в дополнение к мандатному, приведен на рис.3.2



Итак, выше мы рассматривали общие требования, без учета специфики защищаемого системного ПО. Данная специфика, в первую очередь, проявляется, когда речь заходит о следующем (в соответствии с представленными требованиями): «Для каждой пары (субъект - объект) должно быть задано явное и недвусмысленное перечисление допустимых типов доступа …» и «…должен быть применим к каждому объекту и каждому субъекту…».

^ Архитектурные особенности ОС Windows

Теперь, применительно к понятиям «Объект» и «Субъект» рассмотрим архитектурные особенности ОС Windows (в том числе, файловой системы NTFS), накладывающие свои уточняющие требования к корректности реализации в СЗИ НСД дискреционного принципа контроля доступа для ОС данного семейства.

1. Объект доступа.

1.1. В качестве ключевой проблемы корректной реализации рассматриваемых требований отметим проблему возможной неоднозначности идентификации файлового объекта. Это обусловливается тем, что в NTFS файловый объект может быть идентифицирован различными способами.

Рассмотрим эти способы:

Файловый объект идентифицируется именем, при этом:

Файловые объекты, задаваемые длинными именами, характеризуются той отличительной особенностью, что к ним можно обращаться, как по длинному, так и по короткому имени, например к каталогу “\Program files\” можно обратиться по короткому имени “\Progra~1\”;

Файловые объекты, задаваемые русскими (либо в иной кодировке) буквами, также имеют короткое имя, которое формируется с использованием кодировки Unicode (внешне они могут существенно различаться), например, короткое имя для каталога “C:\Documents and Settings\USER1\Главное меню” выглядит как “C:\Docume~1\USER1\5D29~1\”. К этим объектам также можно обратиться, как по длинному, так и по короткому имени;

Файловый объект идентифицируется не только именем, но и своим идентификатором (ID) – индекс объекта в таблице MFT, причем некоторые программы обращаются к файловым объектам не по имени, а именно по ID.

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

С учетом сказанного, можно сформулировать следующее уточняющее требование к корректности реализации механизма в СЗИ НСД – ПРД, задаваемые для файлового объекта, должны быть однозначно определены и действовать при любом из возможных способов идентификации объекта при обращении к нему.

1.2. Другая проблема обусловливается тем, что как собственно ОС, так и некоторые сторонние приложения не позволяют разграничить права доступа для различных пользователей к некоторым файловым объектам (если подобные ПРД назначить, то это приведет к некорректности работы системы или соответствующего приложения). В качестве примера подобного файлового объекта, доступ к которому требует дополнительных разграничений, можно отнести папку: “All Users” на системном диске. Естественно, что выполнение рассмотренного требования является обязательным при категорировании информации, в противном случае, становится невозможным противодействовать понижению категории информации.

С учетом сказанного, можно сформулировать следующее уточняющее требование к корректности реализации механизма в СЗИ НСД – СЗИ НСД должна иметь возможность собственными средствами разделять любую папку, неразделяемую системой и приложениями, между пользователями.

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

С учетом сказанного, можно сформулировать следующее уточняющее требование к корректности реализации механизма в СЗИ НСД – СЗИ НСД должна иметь возможность в полном объеме разграничивать права доступа пользователей к любому файловому объекту, вне зависимости от его функционального назначения.

2. Субъект доступа.

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