На главную | Содержание | Назад | Вперёд
Наши друзья

 

 

Разграничение доступа к системному диску

Процессы в ОС Windows 95/98/ME
В ОС семейства Windows возможен запуск пользовательских (приклад­ных пользователей) и системных (виртуального пользователя «система»)
процессов. При этом некоторые ОС, например, Windows 95/98/ME, не позволяют идентифицировать, относится ли запускаемый процесс к сис­темному, либо к пользовательскому. То есть любой процесс может быть идентифицирован только его именем и именем пользователя, от лица которого он был запущен.
Особенностью системных процессов является то, что для нормального функционирования системы они должны осуществлять не только чтение данных из системного диска (области внешней памяти, где хранятся ка­талоги и файлы собственно ОС), но и запись на системный диск.
Из-за того, что все процессы в ОС Windows 95/98/Ме сопоставляются с пользователем, то разграничение доступа для процессов может сводить­ся к разграничению доступа для пользователей. Если же рассматривать механизмы защиты, реализующие разграничение только для одного типа
субъектов доступа — субъекта «пользователь», то в общем случае доступ к системному диску не может быть запрещен ни для чтения, ни для за­писи. Таким образом, не может быть корректно реализован ни дискре­ционный, ни мандатный механизмы управления доступом, т.к. присут­ствуют объекты, доступ к которым не может быть разграничен между системы.
Проиллюстрируем сказанное с использованием матриц доступа D, где системный диск обозначим как Ос.
В соответствии с введенным ранее определением модель управления доступом на основе произвольного управления виртуальными каналами взаимодействия субъектов доступа в рассматриваемом случае описывает­ся матрицей доступа D, имеющей следующий вид: Аналогично матрица доступа D для полномочной модели управления доступом с комбинированным управлением виртуальными каналами вза­имодействия субъектов доступа в рассматриваемом случае принимает вид,
представленный ниже:
D ■Из анализа приведенных моделей можем сделать вывод о невозможно­сти корректного решения задачи управления доступом к ресурсам (не реализуема каноническая модель доступа) так как существует объект (си­стемный диск), доступ к которому для субъектов «пользователь» раз­граничить невозможно.
Процессы в ОС Windows NT/2000 и UNIX
Для ОС Windows NT/2000, в которых различают пользовательские и си­стемные процессы встроенными в ОС средствами, а также для ОС UNIX, где системные процессы запускаются с правами «root», рассматриваемая проблема имеет иное трактование. Механизмами разграничения прав доступа этих систем может разграничиваться доступ только для пользо­вателей (для пользовательских процессов). Для системных же процессов разграничения установить невозможно в принципе. Это обусловливает очень распространенную атаку — запуск несанкционированного процес­са с системными правами.
Кроме того, не представляется возможным осуществить разграничение
для приложений, запускаемых с системными правами. Это усугубляет
последствия ошибок в данном ПО. Так, если вернуться к существующей статистике угроз, то можем увидеть, что данным угрозам подвержены практически все существующие ОС. Причем доля подобных угроз весь­ма существенна.
Если обозначить группу системных процессов Сс, то, например, модель управления доступом на основе произвольного управления виртуальны­ми каналами взаимодействия субъектов доступа описывается матрицей
доступа D, имеющей следующий вид:
Это наглядно показывает невозможность корректной реализации моде­лей разграничения доступа для современных ОС без возможности раз­граничения доступа для субъекта «ПРОЦЕСС».
Субъект доступа системные процессы и доступ к системному диску
Введем в схему управления доступом субъект доступа «процесс». Разде­лим процессы на системные и пользовательские. При этом для систем­ных процессов установим режим эксклюзивной проверки прав доступа (вне анализа прав доступа пользователей). Этим процессам разрешим в простейшем случае полный доступ только к системному диску («на за­пись» и «на чтение») и запретим доступ к каталогам пользователей.
Всем пользователям запретим права доступа к системному диску «на запись». Права доступа «на чтение» системного диска пользователям оставим, так как в противном случае могут некорректно функционировать приложения.
В результате произведенных установок получаем, что пользователь не смо­жет обратиться к системному диску прикладным процессом «на запись». Таким образом, управление доступом реализуется корректно. При этом любой системный процесс не сможет получить доступ к данным пользова­теля, что в принципе снимает большой круг проблем, связанных с НСД к информации с правами системного процесса. В то же время системные процессы имеют полный доступ к системному диску, либо к необходимым объектам системного диска.
К системным процессам для различных ОС семейства Windows, которым требуется разрешить доступ к системному диску «на запись» для коррект­ного функционирования ОС, относятся KERNEL32, SYSTEM и др.
Привилегированные процессы
Отметим, что в общем случае доступ «на запись» к системному диску может потребоваться разрешить не только системным процессам, но и некото­рым процессам приложений. Например, если в системе реализуется доба­вочная система защиты, которая располагается на системном диске, то ее процессам потребуется обращаться к системному диску «на запись».
Определение.
Процессы, которым при функционировании ОС и приложений требуется об­ращаться к системному диску для записи на него информации, т.е. процес­сы, доступ которых к системному диску требуется разграничивать эксклю­зивно (вне прав пользователей), будем называть привилегированными. Привилегированные процессы — это системные процессы (процессы ОС) и процессы приложений, которым для корректного функционирования необхо­дим доступ «на запись» на системный диск. Как уже отмечалось, примером таких процессов могут служить процессы системы защиты.
Необходимость введения привилегированных процессов обусловлена тем, что на пути реализации мандатного механизма управления доступом си­стемных процессов к файловым объектам возникают определенные слож­ности. Например, в ОС Windows 9X/Me системные процессы запуска­ются с правами текущего пользователя. А значит всем пользователям, независимо от их меток, должен быть разрешен доступ «на запись» и «на чтение» к системному диску. Но при этом мандатный механизм не может быть реализован в принципе, так как к одному объекту имеют право «на запись» пользователи с разными метками.
Данную проблему как раз и позволяет решить выделение привилегиро­ванных процессов, которые должны рассматриваться вне прав пользова­телей. При этом всем пользователям может быть запрещен доступ к системному диску.
Рассмотрим реализацию мандатного механизма управления доступом применительно к способу назначения субъектам и объектам мандатных меток. Сделаем это с учетом разграничений, вводимых для привелигеро-ванных процессов. Для этого рассмотрим матрицу доступа D для ман­датного управления доступом. При этом будем использовать дополнитель­ные метки МО и Mk-i-1, обоснованность которых показана ниже.
Введем следующие предположения:
* будем считать, что привилегированные процессы (соответствующие исполняемые файлы) не могут быть каким-либо образом модифици­рованы пользователем и под их именем не могут быть запущены пользовательские процессы (эта задача решается механизмами обес­печения замкнутости программной среды, которые будут рассмотре­ны ниже);
будем считать, что на системном диске не располагаются пользова­тельские каталоги и файлы (информация). Кстати говоря, это обще­принятая практика организации файловых объектов.
В данных предположениях привилегированным процессам можно назна­чить метку МО — ввести их в группу субъектов СО, а системному диску метку Mk+1 — ввести его в группу объектов При таком назначе-
нии меток безопасности доступ привилегированных процессов не разгра­ничивается и они имеют доступ ко всем файловым объектам. В том чис­ле они имеют полный доступ к системному диску.
Примсчание
В качестве дополнения можно дискреционным механизмом ограничить дос­туп системным процессам только к системному диску (причем только к не­обходимой его части).
Все пользовательские приложения имеют доступ к системному диску только «на чтение». Таким образом мандатный механизм управления доступом реализуется корректно. При этом системный диск не становится тем объектом, доступ к которому «на запись» необходимо разрешать всем пользователям.
Общие рекомендации
С учетом сказанного ранее сформулируем общие рекомендации по уп­равлению доступом к системному диску.
1. Запрещать доступ к системному диску «на запись» следует не только с целью обеспечения корректности реализации управления доступом (отсутствуют несанкционированные каналы взаимодей­ствия субъектов доступа), но и с целью предотвращения модифи­кации файловых объектов ОС. Без защиты ОС от модификации пользователями вообще нельзя говорить о какой-либо защите ин­формации на компьютере.
2. С целью возможного резервирования механизма управления дос­тупом к ресурсам (как основного механизма противодействия НСД) функции разделения процессов на системные и пользовательские должны быть выполнены средствами механизма добавочной защи­ты, т.к. эти функции являются важнейшими функциями механиз­ма управления доступом к ресурсам. Резервирование было рас­смотрено в п. 3.2.
3. Применительно к созданию диспетчера доступа добавочными сред­ствами защиты необходимо реализовывать перечисленные ранее тре­бования к нему. В том числе должно быть выполнено требование: «управление доступом должно осуществляться, как для явных действий  субъекта,   так и для скрытых».
В частности, при реализации диспетчера доступа для ОС Windows NT/2000 следует учитывать то, что при использовании длинных имен файловых объектов к ним можно обращаться и по длинному, и -по короткому име­ни. Например, к каталогу«\Program files\» можно обратиться по корот­кому имени «\Progra~l\». Поэтому при задании правил разграничения доступом при указании пути к файлам или каталогам, следует устанав­ливать права доступа для обоих имен файловых объектов. Понятно, что
они должны быть одинаковыми.
Необходимо также учитывать, что в ОС Windows NT/2000 имена (катало­гов, файлов), набранные русскими (либо в иной кодировке) буквами, также
имеют короткое имя, которое формируется с использованием кодировки Unicode (внешне они могут существенно различаться). Например, корот­кое имя для каталога«C:\Documents and Settings\USERl\rjiaBHoe меню» выглядит как «C:\Docume~l\USERl\5D29~l\». Поэтому при использова­нии русских имен (или иной кодировки) в обозначении файловых объек­тов для покрытия всех видов обращения к таким ресурсам, также следует устанавливать права доступа (одинаковые) для соответсвующих имен фай­ловых объектов. Отметим, что при разработке диспетчера доступа доба­вочного средства защиты информации данные функции могут быть реа­лизованы автоматически.
На основании всего вышесказанного можно сделать вывод, что включе­ние в схему управления доступом субъекта «ПРОЦЕСС», позволяющего средствами механизмов защиты различать пользовательские и привиле­гированные процессы, предоставляет возможность корректной реализа­ции разграничений прав доступа к системному диску и для системных процессов. Корректно реализовать это можно только с помощью средств добавочной защиты. Самими современными универсальными ОС это в
полном объеме не обеспечивается.

 

На главную | Содержание | Назад | Вперёд
 
Яндекс.Метрика