06.03.2002

Технологии для отражения неизвестных атак: часть третья- точно выверенный уровень доступа (Проект SELinux)

Последний метод отражения неизвестных атак использует точно выверенный уровень доступа (fine-grained mandatory access controls), который является основой проекта SELinux - Security Enhanced Linux, разрабатываемого NSAIARG (National Security Administration's Information Assurance Research Group). Механизм SELinux основан на двух ключевых концепциях: fine-grained mandatory access controls и отделении механизмов наблюдения от «полицейских» программ.

Последний метод отражения неизвестных атак использует точно выверенный уровень доступа (fine-grained mandatory access controls), который является основой проекта SELinux - Security Enhanced Linux, разрабатываемого NSAIARG (National Security Administration's Information Assurance Research Group). Механизм SELinux основан на двух ключевых концепциях: fine-grained mandatory access controls и отделении механизмов наблюдения от «полицейских» программ.

Большинство систем имеет очень грубые уровни управлений доступом: так, программа, выполняющая как root (или на эквивалентном уровне доступа в других OS) имеет доступ к каждой функции машины и имеет практически неограниченные возможности для управления системами компьютера. Программы, запущенные пользователем, обычно наследуют уровень доступа пользователя для управления файлами. И словно специально для того, чтобы усугубить и так тяжелую проблему с компьютерной безопасностью, некоторые распространенные функции часто требуют привилегий уровня root. К примеру, sendmail в системах Unix должен иметь возможность беспрепятственно связываться с портом 25 и записывать данные в mailspools пользователя, в то время как другие возможности уровня доступа root (типа способности переводить порты Ethernet в разнообразные режимы) ему не требуются. Таким образом, мы имеем практически готовую систему для управления компьютером, и измененный (вирусом или хакером) sendmail получает возможности, которые никогда не предполагались разработчиками для этой программы. Проблема ясно демонстрируется с червем Code Red II: так как IIS выполняется на системном уровне, то установленный через дыру в защите червь Code Red II мог выполнить фактически любое действие, включая выключение инфицированной машины, стирания данных и даже форматирования диска.

Точно выверенный уровень доступа решает эту проблему. Вместо привилегий, являющихся грубой системой ограничения доступа, адресный доступ гарантирует, что каждый системный вызов уполномочен, как законная функция выполняемой программы, пользователь имеет соответствующий доступ на этот запрос, и реально в программе существует контекст, делающий этот системный запрос. Это может быть очень мощным инструментом, если системы контроля и запретов хорошо написаны. Одна система должна иметь web-сервер, который может только считывать (но не записывать) данные структуры файловой системы, как анонимный пользователь, со способностью записи только в определенные log-файлы. С подобными ограничениями на использование сети и других действий, возможности червей, как класса Code Red, так и любых других, были бы строго ограничены. Если бы вирус даже смог инфицировать web-сервер, то он не смог бы инициализировать новые подключения для размножения, или запустить любую программу, кроме тех, которые данный web-сервер уполномочен выполнять.

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

Такая методика требует небольших, но многочисленных изменений в операционной системе. Практически каждый системный вызов должен быть обработан на предмет соответствия политике защиты, но вся эта долгая и кропотливая работа обработке системных запросов должна привести к «вандалоустойчивой» системе. Существует один, но зато очень важный недостаток такого подхода – получаемая в результате система крайне трудно изменяется и модифицируется, так как при любых даже незначительных изменениях системы необходимо заново составлять и кодировать всю политику защиты, привязывать ее к конкретным системным запросам. Поэтому был предложен другой вариант – метод SELinux, в котором используется "сервер защиты" - отдельная область операционной системы, которая и занимается всеми вопросами проверки на безопасность. Всякий раз, когда операционной системе требуется проверить, позволена ли вызываемая команда, запрашивается сервер защиты, чтобы определить, как текущая политика рассматривает это действие. И только в случае положительного ответа продолжается работа приложения, иначе – действие пресекается. Такой подход обеспечивает максимальную гибкость, поскольку возможно использование различных политик защиты сервера, и глобальная политика защиты может даже быть заменена без остановок в работе основной системы.

Основное преимущество этой методики состоит в том, что это предлагает существенную гибкость системы, очень высокий уровень защиты, и высокую эффективность. Гибкость происходит из способности создания собственных защитных политик для конкретных программ или пользователей с самыми различными целями, от обеспечения изоляции для некоторых серверов до уменьшения вирусного риска ограничением уровня доступа неизвестных программ. Высокий уровень защиты обеспечивается способностью составления всесторонней политики защиты, которая ограничивает каждое приложение непосредственными задачами, которые они должны выполнять. Наконец, высокая эффективность получена из наблюдения, что при таком методе для большинства программ число системных вызовов весьма мало. Так, хотя каждая проверка приводит к существенной (до двадцати пяти процентов) потере времени, многочисленные эталонные и реальные тесты, типа обслуживания web или компиляции, говорят о трех-пяти процентах увеличения полного времени выполнения программы. Если такие (в принципе, небольшие) потери времени по каким-то причинам не устраивают, существует вариант значительного снижения потерь созданием «фиктивного сервера защиты» на той же машине, где находится и основная система.

Два главных неудобства подхода - то, что политика должна быть составлена и настроена очень тщательно, и что механизмы защиты должны быть встроены операционную систему. При хорошем программном исполнении даже заданная по умолчанию политика защиты даст неплохие результаты, но для достижения лучшего будет требоваться самостоятельная настройка под конкретные цели. Интеграция с OS сама по себе не трудна, но, как вы понимаете, должна выполняться теми, кто имеет доступ к исходным программным текстам системы. Для систем Windows при существующем положении вещей никто, кроме самих программистов из Microsoft, не сможет этого осуществить. Но если Microsoft действительно серьезно относится к задаче улучшения защиты, о чем недавно заявляли руководители корпорации, точно выверенный уровень доступа мог бы обеспечить мощную, гибкую и эффективную защиту.

Заключение

Все три метода, обсужденные в цикле статей, обладают существенной особенностью – все они могут (и должны) быть интегрированы в будущие операционные системы. И хотя в системах Windows только Microsoft может добавить точно выверенный уровень доступа, и также только эта корпорация имеет права на использование метода программной изоляции ошибки (правда, этот вопрос необходимо уточнить юристам), остальные технологии могут применяться не только разработчиками, но и третьими лицами. Метод программной изоляции ошибки и метод обнаружения вторжения путем анализа программы могут быть применены к уже откомпилированным программам, так как они предлагают независимые от языка и конкретных приложений решения без изменений в программах или операционных системах.

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

или введите имя

CAPTCHA