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

 

 

Практическая реализация механизмов добавочной защиты

Особенности реализации механизмов добавочной защиты
Организация добавочной защиты операционной системы
Механизм управления доступом к ресурсам (диспетчер доступа) должен выполняться в виде системного драйвера и функционально располагать­ся между приложением и ядром ОС. Это вызвано следующим. На уров­не приложения невозможно осуществить разграничительную политику доступа в принципе. Здесь можно только регистрировать факт уже свер­шившегося события и осуществлять противодействие, если событие не­санкционированное. Реализация диспетчера на уровне ядра, во-первых, практически невозможна для коммерческих систем (без наличия исход­ных текстов), а во-вторых, может быть связана с нарушением лицензи­онных соглашений разработчика.
Любой запрос на доступ к ресурсам от приложения к ядру перехваты­вается диспетчером доступа и анализируется в соответствии с заданны­ми правами доступа к объектам от субъектов. В случае противоречия запрашиваемого доступа разграничительной политике, он отвергается диспетчером, в противном случае доступ к ресурсу разрешается — транс­лируется в ядро ОС.
При наличии в системе встроенного диспетчера доступа механизм доба­вочной защиты должен располагаться перед ним и первым анализиро­вать запрос. Это вызвано необходимостью реализации перенаправления запросов при доступе к общим каталогам («Корзина» и т.д.). Т.е. обра­ботка запроса на доступ к ресурсам в этом случае должна осуществлять­ся по схеме, приведенной 1.
Особенностью реализации механизма управления доступом (диспетчера доступа) к ресурсам добавочной защиты является то, что он полностью должен быть развязан с соответствующим механизмом встроенной защи­ты. В частности, не должен использоваться механизм хранения атрибу­тов доступа файловой системой (например, NTFS). В противном случае настройки механизма добавочной защиты могут быть изменены средства­ми настройки встроенного механизма защиты. Кроме того, в этом слу­чае невозможно говорить о резервировании механизмов защиты.
Остается единственный способ хранения прав доступа к ресурсам -
матрицы доступа (либо соответственно, меток конфиденциальности). Этот способ предусматривает хранение прав доступа в файле (либо в реест­ре), доступ к которому также соответствующим образом разграничивает­ся. Кстати говоря, реализация данного подхода позволяет строить дис­петчер доступа с едиными принципами построения для различных типов файловых систем и для различных видов ресурсов. Принципиальным отличием хранения матрицы доступа в файле является то, что на произ­водительности системы сказывается величина таблицы прав разграниче­ния доступа, анализируемой при каждом доступе к ресурсам.
Рассмотрим, в какой мере сказывается данное влияние (на примере хра­нения таблицы разграничения прав доступа в файле), а также возмож­ные подходы к его уменьшению.
Оценка влияния, оказываемого на вычислительную систему добавочными механизмами защиты
Для исследования влияния на загрузку вычислительного ресурса выбе­рем приложение MS Excel, имеющее наибольший относительный пока­затель потери производительности, и выберем среднюю интенсивность поступления заявок, полученную для MS Excel при расчете характерис­тики моделей.
В табл. 16.1 представлены экспериментальные значения времени, затра­чиваемого на проверку одного запроса к файловому объекту.
Экспериментальные значения времени, затрачиваемого
на проверку одного запроса к файловому объекту Таблица 16.1


Длина списка

Время,

Длина списка

Время,

Длина списка

Время,

(число строк)

МКС

(число строк)

МКС

(число строк)

МКС

10

9

300

278

550

509

50

46

350

324

600

556

100

92

400

370

650

602

150

139

450

417

700

648

250

231

520

481

750

694

2 приведен график роста влияния на загрузку вычислитель­ной системы при увеличении списка (строк в списке) правил разграни­чения доступа в рамках реализации диспетчера доступа добавочными сред­ствами защиты (при фиксированной интенсивности поступления заявок
на обслуживание). Результаты исследований получены с использовани­ем модели, представленной ранее.
Видно, что рост влияния на загрузку вычислительной системы при кон­троле процессов, как самостоятельных субъектов доступа, незначителен, по сравнению с ростом общего процента потерь. Однако общие потери могут быть весьма существенны. И хотя рост времени проверки при уве­личении списка правил разграничения доступа имеет линейную зависи­мость, рост процента потерь производительности имеет показательный характер (например, при 100 строках в таблице разграничения прав дос­тупа потери производительности могут достигать 10%).
Пути уменьшения потерь производительности   вычислительной системы из-за средств защиты
Так как длину списка в 100 строк в общем случае нельзя считать доста­точной для задания правил разграничения доступа (в реальных системах длина списка прав разграничения доступа может достигать 150...200 строк) рассмотрим некоторые пути уменьшения потерь из-за средств защиты. Ясно, что бороться с потерями от введения средств добавочной защиты можно следующими путями:
» путем уменьшения списка правил разграничения доступа; » путем уменьшением времени проверки одного запроса; » сразу обоими методами.
Первый способ интуитивно очевиден: сократить длину имени ресурса (т.е. среднюю длину строки в списке правил разграничения доступа). Например, ресуры файловой системы, доступ к которым подлежит разграничению, следует располагать как можно ближе к корневому каталогу. Это естествен­но уменьшит длину полного имени ресурса, т.е. длину строки в списке.
Недостатком данного подхода является то, что, во-первых, данное огра­ничение (no-сути, разграничение доступа к каталогам) не всегда выпол­нимо в реальной системе, во-вторых, такой способ мало применим для остальных ресурсов вычислительной системы, например реестра или се­тевых ресурсов, так как в этом случае администратор безопасности не может изменять полные имена ресурсов.
Второй способ состоит в использовании масок. Маска — это регулярное выражение, содержащее метасимволы и т.п., покрывающие не-
сколько имен ресурсов сразу. Таким образом, вместо внесения некото­рого количества очень похожих имен ресурсов в списки правил разгра­ничения доступа вносится только одна маска, содержащая общую часть имен этих ресурсов и метасимволы, задающие правила последующего сравнения маски и имен ресурсов.
При использовании механизма масок в ОС семейства MS Windows есть своя особенность. Для таких ОС характерно, что имена файловых ресур­сов не подходящие под формат «8.3» (так называемые, «длинные имена»)
имеют фактически два имени — длинное и короткое в формате «8.3». Это
вынуждает либо вносить в списки правил разграничения доступа оба име­ни, либо использовать в качестве имен ресурсов в этих списках маски.
Так, например, в ОС MS Windows 95/98/Ме, а также в MS Windows NT, короткое имя, получаемое из длинного, содержащего символы, не вхо­дящие в латинский алфавит, формируется по тому же принципу, что и для длинного имени, содержащего только символы латинского алфави­та. То есть, например, длинному имени C:\Program РПе5\Абвгдежзик\аЬс
соответствует короткое имя C:\Progra~ 1\Абвгде~1\аЬс. Оба имени покры­ваются маской следующего вида: С:\Рго§га*\Абвгде*\аЬс.
В ОС MS Windows 2000/Хр, в случае, если длинное имя, содержащее символы, не входящие в латинский алфавит, располагается на файловой системе NTFS, короткое имя формируется с использованием четырехзнач­ного шестнадцатеричного числа, вместо части пути, содержащего сим­волы, не входящие в латинский алфавит. То есть, для приведенного выше длинного имени, короткое имя в таких условиях будет выглядеть так: C:\Progra~l\C6F5~l\abc.
Понятно, что попытка покрытия этих двух имен (длинного и короткого) простой маской обречена на неудачу, так как часть пути к ресурсу, со­держащего символы, не входящие в латинский алфавит, выглядит раз­лично в длинном и коротком имени (не имеет ни одного общего симво­ла). Требуемую маску создать можно, но помимо упомянутых имен такая маска обязательно покроет еще некоторые имена ресурсов.
Подобная ситуация исправляется в случае применения более сложных регулярных выражений для масок. Однако очевидно, что проще органи­зовывать структуру файловой системы NTFS, избегая использования длин­ных имен, содержащих символы, не входящие в латинский алфавит (что
под силу администратору безопасности при настройке системы защиты).
Таким образом, времени проверки одного запроса достига-
ется применением усовершенствованного алгоритма сравнения строк. Кроме того, можно использовать различные математические методы ус­корения поиска (организация списков прав разграничения доступа в виде
сбалансированных деревьев и т.п.).
Учитывая все сказанное, проведем исследование потерь производитель­ности в случае применения модифицированного алгоритма проверки прав доступа. Модификация заключается в замене процедуры посимвольного сравнения строк на процедуру с использованием простейших регулярных выражений. В табл. 16.2 представлены экспериментальные данные вре­мени, требуемого при проверке прав доступа для одного запроса.
Экспериментальные значения времени, затрачиваемого
на проверку одного запроса к файловому объекту Таблица 16.2


Длина списка (число строк)

Время, мкс

Длина списка
(число строк)

Время,
МКС

Длина списка (число строк)

Время,
МКС

10

9

300

278

550

509

50

46

350

324

600

556

100

92

400

370

650

602

150

139

450

417

700

648

250

231

520

481

750

694


При сравнении данных, представленных в табл. 16.1 и 16.2, можем сде­лать вывод о том, что в случае применения модифицированного алгорит­ма проверки и сокращения длины имен ресурсов достигается почти дву­кратное снижение потерь производительности вычислительной системы, связанных с реализацией механизма управления доступом к ресурсам.
ПОДВОДЯ ИТОГИ
Обобщим сказанное ранее в плане рассмотрения преимуществ, реализу­емых рассмотренными выше механизмами управления доступом к ресур­сам. Общая классификация этих преимуществ приведена 3.
Введение новых свойств, например, включение в схему управления до­ступа субъекта «процесс», как ранее показано, позволяет противодей­ствовать целым группам скрытых угроз, например, макросам офисных
приложений.
Реализация принципиально новых подходов, как отмечалось выше, свя­зана с возможностью локализации прав стандартных и оригинальных приложений, возможностями внесения в схему мандатного разграниче­ния субъектов и объектов доступа «ПРОЦЕСС» и т.д. При этом необхо­димо учитываить, что в работе отмечены лишь явные и интуитивно по­нятные подобные возможности, круг которых на практике может быть существенно расширен администратором безопасности с применением за­ложенных в рассмотренные механизмы технологий управления доступом.
В части упрощения администрирования механизмов защиты рассматрива­ется принципиально новый подход к администрированию важнейшего ме­ханизма — обеспечения замкнутости программной среды. Посредством контроля списков процессов, разрешенных к запуску, данный механизм
корректно настроить, а уж тем более модифицировать исходные настрой­ки в процессе функционирования системы, если не невозможно, то чрез-
сложно. Рассмотренный же подход к администрированию, позво­ляющий администратору работать не со списками, а с каталогами, из ко­торых разрешается запуск процессов, принципиально упрощает как про­цедуру исходной настройки, так и модификацию настроек в процессе функционирования системы защиты.
В качестве примера противодействия скрытым угрозам приведем пример атаки, на первый взгляд, казалось бы, никак не связанной с механизма­ми управления доступом к ресурсам, и рассмотрим возможность проти­водействия данной атаке с использованием рассмотренных подходов.
Рассмотрим одну из атак, позволяющих несанкционированно запустить исполняемый код. Атаки этого типа основываются на переполнении бу­фера входных данных различных программ. Атакам данного типа в основ­ном подвержены Unix-системы, что во многом обусловливается организа­цией разграничения прав в подобных системах встроенными средствами.
Целью атаки является повышение привилегий злоумышленником. Это связано с тем, что некоторые программы (обычно системные демоны или
программы настройки) требуют для своей работы привилегий админист­ратора системы (root). Например, сетевые серверы ftp, http, bind и др. работают в системе с правами root.
Кроме того, программы настройки чего-либо обычно тоже требуют по­вышения привилегий, т.к. им зачастую необходимо модифицировать
файлы в системном каталоге /etc, что позволено только root.
Атака на переполнение буфера входных данных используется для того, чтобы заставить атакуемую программу запустить другую (например, стан­дартную для всех Unix-систем командную оболочку /bin/sh). Атакуемая
программа является программой настройки и имеет привилегии root.
В результате переполнения стека программа начинает выполнять код, занесенный в стек злоумышленником. Например, этот код может выпол­нять системные вызовы setuid() и ехес(). Это приводит к порождению нового процесса (командной оболочки) также с правами root, что позво­ляет злоумышленнику отдавать команды системе уже от имени root.
Противодействовать подобным атакам с использованием встроенных ме­ханизмов защиты очень сложно. Необходимо постоянно обновлять про­граммное обеспечение, где обнаруживаются уязвимости такого типа. И все
равно, даже в обновленной версии программ, нет гарантии, что все ошибки, приводящие к переполнению буфера входных данных, исправлены. Зна­чительно усложняет ситуацию и то, что с помощью стандартных, т.е. вхо­дящих в состав ОС, средств разграничения прав доступа, невозможно ог­раничить набор доступных для привилегированного процесса ресурсов.
Реализация рассмотренного метода проверки запросов к ресурсам вычис­лительной системы позволяет исключить в принципе возможность по-
атак. Так как в рамках данного метода возможно управлять пра­вами конкретного процесса, то становится возможным ограничить набор доступных ресурсов для привилегированного процесса.
Таким образом, указанием в списке доступных для процесса ресурсов имен только тех ресурсов, доступ к которым ему необходим, автомати­чески исключается возможность осуществить с помощью этого процесса НСД к другим ресурсам, в том числе, и с целью выполнения.
Например, для противодействия возможности рассматриваемой атаки
достаточно указать в списке доступных для программы ресурсов только файлы, доступ к которым ей необходим. Если такие файлы неизвестны, то можно разрешить доступ программе (/usr/openwin/bin/kcms_configure) только в каталоги настроек тем самым исключая
доступ к каталогам, содержащим исполняемые файлы.
Таким образом, исключается не только возможность запустить с помо­щью такой атаки некоторый процесс с привилегиями root, но также осу­ществить НСД к другим объектам системы. Действительно, поскольку атакуемая программа обладает неограниченными привилегиями (в слу­чае использования встроенных в ОС механизмов защиты), можно с по­мощью атаки подобного типа осуществить НСД к ресурсам, недоступ­ным злоумышленнику по существующим разграничениям прав доступа. И тем же способом, то есть ограничивая доступ программе только фай­лами, непосредственно принадлежащими ей, исключаются и атаки, ис­пользующие переполнение буфера для НСД к ресурсам системы.
Мы привели только один пример противодействия целой группе атак с
целью иллюстрации эффективности рассматриваемых подходов. Однако
данный пример, с одной стороны, иллюстрирует эффективность рассмат­риваемых подходов, с другой стороны, показывают и потенциальные сложности, связанные с противодействием скрытым атакам.
Кроме того, на этом примере иллюстрируется следующая идея: любая система защиты, в том числе и добавочной, предлагает администратору
безопасности лишь набор механизмов защиты. Эффективность же исполь­зования возможностей механизмов защиты является важнейшей задачей
администратора безопасности.
Другими словами, защищенность системы определяется не только воз­можностями системы защиты, но и квалификацией администратора бе­зопасности, настраивающего данную систему -- реализующего возмож­ности системы защиты. При этом в функции администратора должно быть включено не только решение задачи реализации разграничительной по­литики доступа к ресурсам, предоставляемыми возможностями системы
защиты, но и настройка системы защиты с целью противодействия воз­можным угрозам, в том числе скрытым.
В нашей работе рассматриваются лишь общие подходы к построению си­стемы защиты, определить же требования к настройке рассматриваемых механизмов защиты для противодействия известным группам атак, ис­пользуя данные материалы, интересующемуся читателю предлагается са­мостоятельно.

 

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