Щеглов А.Ю. Защита компьютерной информации от несанкционированного доступа

Подождите немного. Документ загружается.

Глава 14. Субъект доступа «Процесс» и его учет при разграничении доступа

Исполняемые файлы в общем случае имеют признаки, по которым их

всегда можно отличить от файлов данных. Например, для ОС семейства

Windows исполняемые файлы по внешним признакам отличаются рас-

ширениями (например,

.com,

.exe и т.д.). В ОС UNIX отличительным

признаком исполняемых файлов может служить их атрибут исполнения.

Однако

интерпретаторы

команд (например, встроенный в ОС процесс

CMD.exe) позволяют запускать файлы с иным расширением. Поэтому в

общем случае необходимо уметь выделять исполняемые файлы, исходя

из их структуры, то есть определять, исходя из внутренних признаков.

Здесь будет идти речь об исполняемых файлах прикладных программ. Воп-

росы разграничения доступа к системным исполняемым файлам (к привиле-

гированным процессам) рассмотрены выше.

Управление доступом к исполняемым файлам реализует разграничение

прав доступа субъектов на запуск прикладных программ.

Для разграничения доступа субъектов к исполняемым файлам введем

право доступа «И» -- «исполнение» — чтение исполняемого файла (за-

пуск программы), тогда множество прав доступа в общем случае имеет

вид

{Зп,

Чт, Д,

И}.

14.8.1. Каноническая модель

управления доступом к исполняемым файлам

Используя обозначения, введенные ранее, введем следующее обозна-

чение: пусть S

(О,

И}

— множество прав доступа, где «О» обозначает

отсутствие доступа субъекта к объекту, «И» — доступ к исполняемому

файлу (разрешение чтения исполняемого файла). Тогда, по аналогии

со сказанным ранее, каноническую модель управления доступом к ис-

полняемым файлам можно представить матрицей доступа D, имеющей

следующий вид:

О,

о.

с,

0 ..

и ..

0 ..

•

Q-i

.. 0

. 0

. и

231

Часть IV. Управление доступом к ресурсам

Модель управления доступом формально может быть описана следующим

образом: элемент (Dij) матрицы Dij = И, если i = j, иначе Dij = 0.

Под канонической моделью управления доступом к исполняемым файлам

для линейно упорядоченных множеств субъектов доступа (групп субъектов)

и объектов доступа (групп объектов) понимается модель, описываемая мат-

рицей доступа, элементы главной диагонали которой

<41»

задают доступ к

исполняемому файлу (разрешение на запуск программы), остальные элемен-

ты «О» задают запрет доступа субъектов к исполняемым файлам.

-JK

»Д1=

Диспетчер доступа реализует механизм управления доступом к исполняе-

мым файлам корректно только в том случае, если его настройками (задани-

ем учетных записей субъектов и объектов доступа и правил разграничения

доступа) можно реализовать каноническую модель управления доступом.

Доказывается утверждение от обратного. Если каноническую модель

управления доступом реализовать невозможно — присутствуют элемен-

ты «И» вне главной диагонали матрицы доступа, то в системе присут-

ствует по крайней мере один объект — программа, доступ к запуску ко-

торой невозможно разграничить в полном объеме (объект включается

одновременно в несколько групп объектов, априори характеризуемых

различными правами доступа к ним).

По аналогии со сказанным ранее, в рассматриваемом случае в канони-

ческую модель управления доступом также должны быть включены ка-

налы взаимодействия субъектов доступа. В противном случае, субъекты,

имеющие возможность обрабатывать информацию только различными

приложениями, не смогут обменяться информацией.

Таким образом, включение канала взаимодействия субъектов в матрицу дос-

тупа означает разрешение запуска субъектами одного и того же приложения.

В матрице доступа D это означает включение группы (групп) объектов,

для которых несколько субъектов будут иметь доступ. Пример такой мат-

рицы приведен ниже. При этом в нее введена группа объектов (программ)

Ок+1,

доступ к которым (запуск которых)

разрешен

всем субъектам.

о,

о„

*.,

" я

я я

232

Глава 14. Субъект доступа «Процесс» и его учет при разграничении доступа

По аналогии управления доступом к файлам данных, здесь может быть

реализован дискреционный и мандатный механизмы управления. Диск-

реционный механизм предполагает реализацию доступа диспетчером на

основе заданной матрицы доступа D, а мандатный

--на

основе меток

безопасности.

Метки безопасности являются элементами линейно упорядоченного мно-

жества М =

{Ml,...,Mk}

и задаются субъектам и объектам доступа. Метки

безопасности назначаются субъектам и объектам (группам субъектов и объек-

тов) и служат для формализованного представления их уровня полномочий.

Как и ранее, будем считать, что чем выше полномочия субъекта и объекта,

тем меньшее значение метки безопасности Mi,

= l,...,k им присваивается,

т.е.: Ml < М2 <

M3<...<Mk.

При этом в линейно полномочно упорядочен-

ных множествах С =

{С1,...,Ск}

и О =

{Ol,...,Ok}

субъекты и объекты рас-

полагаются в порядке уменьшения полномочий (уровня безопасности).

14.8.2. Каноническая полномочная модель

управления доступом к исполняемым файлам

Каноническая полномочная модель управления доступом к исполняемым

файлам может быть представлена следующей матрицей доступа D.

[И

И ... И

'и

... и

... 0

и '

Модель управления доступом формально может быть описана следующим

образом: элемент матрицы Dij

И, если i <=

иначе Dij = 0.

Под канонической моделью управления доступом к исполняемым файлам с

виртуальными каналами взаимодействия субъектов доступа для линейно

полномочно упорядоченных множеств субъектов (групп субъектов) и

объектов (групп объектов) доступа понимается модель, описываемая мат-

рицей доступа, элементы главной диагонали которой и элементы, рас-

положенные выше главной диагонали, «И» — задают право доступа «Ис-

полнение», остальные элементы матрицы «О» - - запрет запуска

исполняемого файла.

Рассмотрим правила разграничения доступа для модели управления дос-

тупом к исполняемым файлам. При этом воспользуемся введенными ранее

обозначениями:

233

Часть IV. Управление доступом к ресурсам

» Ms — метка безопасности субъекта (группы субъектов) доступа;

» Мо — метка безопасности объекта (группы объектов) доступа;

» метка безопасности Mi с порядковым номером i устанавливается для

субъекта доступа Ci с порядковым номером i и для объекта доступа

Oi с порядковым номером i.

Правила разграничения доступа для модели управления доступом к ис-

полняемым файлам:

1. субъект С имеет доступ к объекту О в режиме «Исполнение» в

случае, если выполняется условие: Мс => Мо;

2. субъект С не имеет доступ к объекту О в режиме «Исполнение» в

случае, если выполняется условие: Мс < Мо.

Выводы:

1. В схеме управления доступом в качестве отдельного объекта досту-

па следует рассматривать исполняемый файл (процесс). В этом

случае должно рассматриваться дополнительное право доступа «ис-

полнение». Использование данного объекта позволяет разграничи-

вать права доступа для субъектов (в общем случае для пользовате-

лей и процессов) по запуску процессов.

2. Условие корректности разграничений для объекта доступа «испол-

няемый файл» задаются точно так же (аналогичные канонические

модели), как и для файловых объектов данных, с учетом права

доступа «исполнение».

14.9. Механизм обеспечения

замкнутости программной среды

14.9.1. Механизм обеспечения замкнутости

программной среды и его роль в системе защиты

Под обеспечением замкнутости программной среды понимается локали-

зация прикладных программ для пользователей. Осуществляется это ме-

ханизмом управления доступом к исполняемым файлам.

Механизм обеспечения замкнутости программной среды реализован коррек-

тно только в том случае, если выполняются требования к полноте управле-

ния доступом к исполняемым файлам.

Проиллюстрируем сказанное примером. Например, для ОС Windows NT/2000

могут устанавливаться разграничения на исполнение файлов (запуск про-

грамм) с жесткого диска. Однако данные ОС не позволяют управлять

234

Глава 14. Субъект доступа «Процесс» и его учет при разграничении доступа

запуском программ с внешних устройств ввода. Поэтому корректно обес-

печить замкнутость программной среды, с целью локализации приклад-

ных программ для пользователя, возможно лишь при отключении вне-

шних устройств ввода.

Таким образом, разграничение доступа на запуск исполняемого файла и

обеспечение замкнутости программной среды не одно и то же. Замкну-

тость программной среды реализуется посредством механизма управле-

ния доступом на запуск к исполняемым файлом, но можно говорить о

его реализации в системе лишь при выполнении требований к полноте

подобных разграничений.

Как отмечалось ранее, несмотря на то, что в современных универсальных

ОС присутствует механизм управления доступом к запуску процессов, ме-

ханизм обеспечения замкнутости программной среды в них не реализован.

Это объясняется невыполнением требований к полноте разграничений -

для ОС Windows исполняемый файл может быть запущен с внешнего уст-

ройства ввода, например, посредством дискеты. В ОС семейства

UNIX

не-

возможно установить атрибут «исполнение» на каталог (под этим атрибу-

том для каталога подразумевается «обзор»), т.е. невозможно запретить запуск

из каталога. При этом (этот вопрос ранее рассматривался) пользователь сам

может присвоить атрибут создаваемому им файлу, т.е. пользователь может

записать в свой каталог исполняемый файл, установить на него для себя

право исполнения, затем запустить данный файл.

Обеспечение замкнутости программной среды -- это важнейший меха-

низм противодействия организации пользователем скрытых каналов до-

ступа к ресурсам защищаемого объекта. Целью применения механизма

является предоставление пользователям возможности запускать только

санкционированные программы из заданных для них списков. При этом

предотвращается возможность запуска пользователем собственной про-

граммы, которая может содержать скрытый канал доступа к ресурсам. Без

реализации данного механизма в системе защиты вообще не приходится

говорить о какой-либо защищенности объекта [11, 12, 19].

В общем случае механизм обеспечения замкнутости программной среды

предназначен для локализации программного обеспечения на компью-

тере (системного, функционального и прикладного ПО) и обеспечение

невозможности запуска пользователем несанкционированного процесса

(программы). Благодаря этому обеспечивается то, что пользователь мо-

жет работать на компьютере только жестко в рамках своих функциональ-

ных обязанностей и инструкций, т.е. в границах списка санкционирован-

ных действий. К этой же задаче относится защита от проникновения

(прежде всего из сети) и запуска на компьютере деструктивных программ

(троянов, программ sniffer клавиатуры и канала, программ взлома или под-

бора паролей, программ перепрограммирования BIOS, инструментальных

средств и т.д.).

235

Часть IV. Управление доступом к ресурсам

Если вернуться к рассмотрению существующей статистики угроз (приве-

денной в п. 2.2), то можем сделать вывод, что подавляющая их часть тре-

бовала от пользователя запуска программного средства, реализующего дан-

ные угрозы. Таким образом, путем предотвращения возможности запуска

пользователем собственных программ злоумышленник лишается собствен-

но инструментария взлома. При этом неважно, о какой угрозе, о какой

цели и способе атаки идет речь. Поэтому данный механизм позициони-

руется нами как основной механизм защиты, позволяющий противодей-

ствовать скрытым угрозам НСД к информации.

Ранее нами отмечалось, что защита информации — это комплексная за-

дача, решение которой достигается реализацией совокупности механизмов

защиты и что невозможно рассматривать механизм защиты в отдельнос-

ти, т.к. найдутся угрозы данному механизму, которые должны предотвра-

щаться другими механизмами. Рассмотрим иную сторону этой проблемы,

когда использование в системе защиты одного механизма может принци-

пиально изменить требование к другим механизмам.

С учетом применения механизма обеспечения замкнутости программной

среды могут существенно снижаться требования к реализации других

механизмов защиты. Рассмотрим пример.

Ввиду того, что при удалении информации с диска осуществляется лишь

переразметка диска, а собственно информация на нем остается, появля-

ется скрытый канал в виде возможности несанкционированного доступа

к остаточной информации на диске. Данный канал может быть устра-

нен, если реализовать механизм гарантированного удаления информации,

который будет заключаться:

В перехвате обращения приложения к ядру ОС «на удаление» объекта.

2. В записи в объект маскирующей информации (осуществляется

N — кратная запись «О» и

«1»),

3. В передаче ядру ОС запрос «на удаление» объекта.

При этом остаточной информации на диске не остается. Реализация дан-

ного механизма защиты связана с существенными потерями производи-

тельности защищаемого объекта. Остаточная информация также может

оставаться в оперативной памяти после завершения процесса (если ОС

или приложение не осуществляет ее очистку).

Однако стандартным приложением прочитать остаточную информацию

не представляется возможным, для этого нужны специальные програм-

мы, запуск которых на компьютере предотвращается механизмом обес-

печения замкнутости программной среды. Таким образом, прочитать

остаточную информацию без запуска несанкционированнорго процесса

на защищенном компьютере становится невозможно. Остается только

одна возможность ее прочтения — это удалить с компьютера жесткий диск

и считать информацию с него на другом компьютере. Но если такое воз-

236

Глава 14. Субъект доступа «Процесс» и

его

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

можно, то оберегать уже следует не остаточную, а актуальную информа-

цию на диске, для чего, в рассматриваемых предположениях, должны

применяться криптографические методы защиты информации на диске.

Сказанное в полной мере относится и к защите оперативной памяти.

Вместе с тем, учитывая, что критичной ситуацией здесь является запуск

несанкционированного процесса пользователем, механизм очистки памя-

ти, на

наш

взгляд, следует запускать в качестве реакции на обнаружение

запущенного несанкционированного процесса. Механизм, реализующий

данную возможность, рассматривается в следующей главе.

Могут быть приведены и иные примеры, когда использование в системе

механизма обеспечения замкнутости программной среды либо делает

необязательными целый ряд других механизмов защиты, либо существен-

но изменяются требования к решаемым ими задачам.

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

замкнутости программной среды -- важнейший механизм, который обяза-

тельно должен присутствовать в системе защиты, т.к. этот механизм мож-

но позиционировать, как основной механизм противодействия скрытым уг-

розам (возможности реализации неизвестной угрозы, присутсвующей в

несанкционированной пользовательской программе).

Ввиду того, что данный механизм не имеет корректной реализации в

современных ОС, его следует реализовать добавочными средствами за-

щиты информации. В противном случае невозможно говорить о возмож-

ности противодействия скрытым угрозам в принципе.

Механизм обеспечения замкнутости программной среды может быть ре-

ализован двумя способами:

» в виде задания списков исполняемых файлов;

* в виде задания каталогов исполняемых файлов.

Рассмотрению и анализу обоих этих подходов посвящен следующий раз-

дел книги.

14.9.2.

Реализация механизма обеспечения

замкнутости программной среды

Посредством задания списков исполняемых файлов

Данный механизм состоит в задании для каждого пользователя списка про-

цессов (исполняемых файлов), которые ему разрешено запускать. Коррект-

ность

функционирования

механизма связана с предотвращением явных и

скрытых каналов модификации списка санкционированных исполняемых

файлов, а также запуска исполняемых файлов, не вошедших в список.

237

Часть IV. Управление доступом к ресурсам

ц[Ш1ддмп;гд

При данном походе объект доступа в матрице доступа к исполняемым

фай-

лам представляет собой список исполняемых файлов.

Требования к корректности функционирования механизма обеспечения

замкнутости программной среды таковы

[30]:

» исполняемый файл должен быть задан с указанием его полного пути,

что предотвращает возможность запуска

несанкционированого

процес-

са с таким же именем из другого места. При этом пользователю дол-

жен быть запрещен запуск программ с внешних устройств ввода (ло-

кальных и общих — разделяемых в сети), а также из общих папок

(разделяемых в сети файловых объектов), т.к. иначе невозможно про-

тиводействовать запуску несанкционированной программы пользова-

теля с полнопутевым именем легальной программы;

* пользователю должен быть задан список санкционированных для его

запуска исполняемых файлов, к которым ему должен быть разрешен

доступ «на исполнение». Ко всем другим файловым объектам пользо-

вателю должен быть запрещен доступ «на исполнение»;

* пользователю должен быть запрещен доступ «на запись» и «модифика-

цию» к исполняемым файлам. В противном случае он сможет подме-

нить санкционированный файл другого пользователя. Особенно это

критично по отношению к системным процессам, поскольку нельзя

допускать, чтобы пользователь мог подменить его собственным несанк-

ционированным процессом. Из сказанного следует, что механизм обес-

печения замкнутости программной среды не может быть корректно

реализован без запрета доступа «на запись» и «на модификацию» к

системному диску и без возможности управлять доступом на исполне-

ние программ с устройств ввода, с разделяемых в сети ресурсов (уст-

ройств и файловых объектов).

Рассмотренный подход интуитивно понятен, но имеет существенные недо-

статки. Главным из них является необходимость перечислять в списках все

процессы, разрешенные к запуску пользователем, в том числе и процессы,

порождаемые уже разрешенными процессами. Из-за этого списки разрешен-

ных процессов становятся очень громоздкими, существенно снижается про-

изводительность системы за счет больших затрат времени на анализ таких

списков при каждом обращении к объекту файловой системы

Сильно усложняется администрирование подобной системы

защиты,

так

как администратору приходится составлять такие списки для каждого

пользователя, а при добавлении новых программ изменять списки у каж-

дого пользователя. Соответственно, при удалении некоторой программы

приходится удалять из множества списков не только саму программу, но

и все процессы, порождаемые удаляемой программой. Кроме того, воз-

никает проблема, связанная с необходимостью введения в список разре-

238

Глава

14.

Субъект доступа «Процесс» и его учет при разграничении доступа

шенных

некоторому пользователю процессов отладочных и иных про-

грамм, которые необходимо запускать эксплуатационным службам при

работе этого пользователя в системе. С другой стороны, необходимо ис-

ключить возможность прямого запуска этих отладочных профамм несан-

кционированным пользователем.

Посредством каталогов исполняемых файлов

Обеспечить замкнутость программной среды можно не непосредственно

заданием списков разрешенных к запуску процессов, а областью диско-

вого пространства (каталогом), откуда пользователю можно запускать

процессы. То есть пользователю можно разрешать/запрещать не что за-

пускать, а откуда запускать. Другими словами, для каждого пользователя

может быть выделен каталог, только из которого ему будет дозволено

запускать программы. На этот каталог должно быть установлено право

«Исполнение» для пользователя. Причем в данный каталог ему должен

быть запрещен доступ «на запись» и «на модификацию», с целью пре-

дотвращения возможности внесения в данный каталог других, не разре-

шенных к запуску программ, а также с целью предотвращения возмож-

ности модификации расположенных в каталоге программ.

При этом из всех остальных каталогов (а также с устройств ввода), кро-

ме системного, пользователю должен быть запрещен запуск программ.

Кроме того, пользователю должен быть запрещен доступ «на запись» и

«на модификацию» в системный каталог. Это необходимо с целью пре-

дотвращения возможности модификации системного каталога — занесе-

ния в него несанкционированных

процессов).

Список разрешенных к запуску профамм (не процессов) определяется

набором профамм, инсталлированных администратором безопасности в

каталог, откуда пользователю разрешен их запуск [11, 12, 19].

Можем сформулировать следующие требования к корректности функци-

онирования рассматриваемого механизма:

« для пользователя должен быть задан каталог, откуда ему разрешено

запускать

профаммы.

На доступ к этому каталогу пользователю дол-

жно быть установлено право «Исполнение», а доступ «на запись» и

«на модификацию» должен быть запрещен;

* в этот выделенный каталог администратором должны быть инсталли-

рованы профаммы, разрешенные пользователю для запуска;

» ко всем остальным каталогам, а также к усфойствам (дисководу, CD-

ROM и т.д.), разделяемым сетевым ресурсам пользователю должен

быть запрещен доступ «Исполнение»;

* к системному диску, а также к каталогам с исполняемыми файлами

остальных пользователей, пользователю должен быть запрещен дос-

туп «на запись» и «на модификацию».

239

Часть IV. Управление доступом к ресурсам

Достоинством рассмотренного здесь механизма является серьезное упро-

щение его администрирования, т.к. исключается необходимость перечис-

ления всех процессов, которые запускает программа, при разрешении ее

запуска пользователем (при установке и удалении программы из списка

разрешенных к запуску). Кроме того, в предыдущей реализации механизма

обеспечения замкнутости программной среды необходимость подобного

перечисления могла привести к тупикам. Например, программе для ра-

боты может потребоваться некоторый процесс, а разрешать запускать этот

процесс пользователю нельзя.

На рис. 14.3 приведена схема обработки запроса доступа к объекту, реа-

лизуемая диспетчером доступа в КСЗИ «Панцирь» с целью обеспечения

замкнутости программной среды [31].

Рис. 14.3. Схема обработки запроса доступа к объекту при реализации

механизма обеспечения замкнутости программной среды

Работает система обеспечения замкнутости программной среды следующим

образом. С входа/выхода 4 производится авторизация пользователя (иден-

тификация и аутентификация) при входе в систему. В случае, если ему

разрешен вход в систему, то его имя через вход 2.6 поступает на вход бло-

ков 2.2. и 2.4. В противном случае блоком 1 со входа/выхода 4 пользова-

тель извещается об отсутствии у него прав на доступ в систему.

После получения доступа в систему, при обращении к файлу запрос на

доступ к файлу со входа 5 поступает через вход 2.7 в блок 2.1. Запрос

содержит: имя процесса, обращающегося к файлу, полный путь распо-

ложения файла в блоке 3, команду над файлом (чтение, запись и т.д.).

Данный запрос анализируется блоком 2.1, который выявляет, является

ли этот запрос от системного или пользовательского процесса.

240