предположении, что программы могут запускаться из двух каталогов Windows и Program Files (т.е. в Program Files администратором устанавливаются все приложения), получаем настройки соответствующего механизма защиты, приведенные на рис.2.
Рис.2. Настройка механизма обеспечения замкнутости программной среды для субъекта «процесс»
Здесь для задания объектов доступа мы использовали переменные среды окружения. При таких настройках запуск программ любым пользователем (разграничения задаются для субъекта доступа «процесс») становится возможен только из текущих (системных) каталогов Windows и Program Files. При необходимости (если программы администратором устанавливаются не только в каталог Program Files) ресурсы, разрешенные для выполнения, для конкретного компьютера могут быть расширены.
Как видим, такой сложный механизм защиты, как обеспечение замкнутости программной среды, настраивается несколькими строками в интерфейсе, причем данные настройки легко тиражируемы и могут устанавливаться «по умолчанию» при инсталляции средства защиты. Данный механизм защиты позволяет в принципе предотвратить запуск на защищаемом компьютере злонамеренной (вредоносной) программы, не требует проведения какого-либо сигнатурного анализа. Попытки же занесения злонамеренной (вредоносной) программы на компьютер могут быть выявлены с использованием соответствующих средств аудита.
В общем случае возможны совершенно различные подходы к решению рассматриваемой задачи защиты.
Рассмотрим альтернативный способ решения с заданием разграничений для учетных записей, см. рис.3.
Рис.3. Настройка механизма обеспечения замкнутости программной среды для субъекта «пользователь»
В приведенном на рис.3 примере настройки, пользователю Sheglov разрешен запуск программ только из каталогов С:\Windows, C:\Program Files, а так же из каталога F:\The Bat, которые ему запрещено модифицировать – не разрешены для записи.
Однако не следует забывать о разнородности вредоносного кода, что, в том числе, определяет и различные способы его запуска. Дело в том, что деструктивные программы могут запускаться, как под учетной записью пользователя, так и под системными учетными записями, например, System, что, в первую очередь, характерно для эксплойтов. С широкими правами создается учетная запись при установке СУБД и т.д. При этом необходимо учитывать, что ошибки программирования могут обнаруживаться как в системном, так и в прикладном ПО.
Как же должна быть реализована защита от запуска деструктивных программ в общем виде, позволяющая эффективно противодействовать их запуску под любой учетной записью, в том числе, и под системной?
Пример настройки механизма защиты, в полном объеме реализующей требования к полноте и к корректности реализации разграничительной политики доступа, приведен на рис.4.
Рассмотрим, что мы получаем при таких настройках – любому процессу (субъект доступа – процесс, задается маской «*») разрешается выполнение процессов только из соответствующих двух папок на системном диске, при этом запрещается любая возможность (опять же, любым процессом, в том числе и системным) модификации данных папок. Т.е. любой несанкционированный исполняемый файл запустить становится невозможно в принципе. При этом получаем, что пусть ваш компьютер «напичкан» вредоносным кодом – эксплойтами, деструктивными и шпионскими программами, троянами, вирусами (здесь рассматриваем именно вирусы – программы, призванные модифицировать исполняемый код разрешенных к запуску программ), запустить-то его невозможно никаким образом!
Однако вернемся к разграничениям, приведенным на рис.4. Специалист, представляющий себе архитектуру современных ОС семейства Windows, нам возразит – при подобных настройках система работать не будет, мы увидим «синий экран», и он окажется прав. При подобных настройках система работать не сможет, требуются уточняющие настройки. Дело в том, что некоторые системные процессы должны иметь право записи в соответствующие файловые объекты на системном диске. Их не так много (не более десятка). К таким процессам, например, могут быть отнесены: winlogon.exe, lsass.exe, csrss.exe, svchost.exe, services.exe и некоторые другие.
Заметим, что данное свойство современных ОС семейства Windows определяет огромный их архитектурный недостаток – невозможность запретить модификацию системного диска системным пользователям (в частности, System), как следствие, и всем системным процессам, а также иным процессам, запускаемым под этой учетной записью (т.к. возможность реализации разграничительной политики доступа для субъекта «процесс» здесь отсутствует). Вот результат – невозможность какого-либо противодействия атакам, связанным с уязвимостями, предоставляющими возможность получение злоумышленником системных прав – записывай на системный диск эксплойт и запускай!
Однако, если в качестве субъекта доступа выступает сущность «процесс»
Уважаемый посетитель!
Чтобы распечатать файл, скачайте его (в формате Word).
Ссылка на скачивание - внизу страницы.
